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Preface 



This volume contains the papers presented at the 4 h F 1 1 e at a S 
i F c t a a d L gtc P g a i g (FLOPS’99) held in Tsukuba, 

Japan, November 11-13, 1999, and hosted by the Electrotechnical Laboratory 
(ETL). FLOPS is a forum for presenting and discussing all issues concerning 
functional programming, logic programming, and their integration. The sympo- 
sium takes place about every 1.5 years in Japan. Previous FLOPS meetings were 
held in Fuji Susuno (1995), Shonan Village (1996), and Kyoto (1998). 

There were 51 submissions from Austria (|), Belgium (2), Brazil (3), China 
(1), Denmark (2), France (3|), Germany (8), Ireland (1), Israel (|), Italy (1]^), 
Japan (9^), Korea (1), Morocco (1), The Netherlands (1), New Zealand (1), 
Portugal (i), Singapore (i), Slovakia (1), Spain (4|), Sweden (1), UK (4|), 
and USA (2|), of which the program committee selected 21 for presentation. In 
addition, this volume contains full papers by the two invited speakers, Atsushi 
Ohori and Mario Rodriguez- Artalejo. 

FLOPS’99 was organized in cooperation with the Special Interest Group on 
Principles of Programming of the Japan Society of Software Science and Technol- 
ogy. The following sponsors provided financial support: Grant-in- Aid for Scien- 
tific Research on Priority Area “Discovery Science” of the Ministry of Education, 
Science, Sports and Culture of Japan, Electrotechnical Laboratory (ETL), Tokyo 
Institute of Technology, University of Tsukuba. Springer- Verlag kindly agreed 
to publish the proceedings in their LNCS series. 
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Semantics and Types in Functional Logic 
Programming* 



J. C. Gonzalez-Moreno, M. T. Hortala-Gonzalez, and M. Rodriguez-Artalejo 

Dpto. Sistemas Informaticos y Programacion, UCM, Madrid 
{ jcmoreno ,teresa,mario}@sip .ucm. es 



Abstract. The rewriting logic CRWL has been proposed as a semantic 
framework for higher-order functional logic programming, using applica- 
tive rewriting systems as programs and lazy narrowing as the goal solving 
procedure. We present an extension of CRWL with a polymorphic type 
system, and we investigate the consequences of type discipline both at the 
semantic level and at the operational level. Semantically, models must be 
extended to incorporate a type universe. Operationally, lazy narrowing 
must maintain suitable type information in goals, in order to guarantee 
well-typed computed answers. 

1 Introduction 

Research on functional logic programming (FLP, for short) has been pursued 
for longer than ten years, aiming at the integration of the best features of func- 
tional programming (FP) and logic programming (LP). In this paper, we will 
investigate the integration of two fundamental characteristics: , 

mainly developed in the LP field, and . . , best understood in FP 

languages. Regarding the FP side, we will restrict our attention to 
languages such as Haskell [17], whose adventages from the viewpoint of declar- 
ative programming are widely recognized. Thanks to lazy evaluation, functions 
in a non-strict language can sometimes return a result even if the values of some 
arguments are not known, or known only partially, and the semantic values in- 
tended for some expressions can be infinite objects. In the rest of the paper, 
“FP” must be understood as “non-strict FP” . 

Logical semantics characterizes the meaning of a pure logic program V (a set 
of definite Horn clauses) as its least Herbrand model, given by the set of all 
the atoms that are logical consequences of V in Horn logic [1]. Disregarding 
those proposals without a clear semantic basis, most early approaches to the 
integration of FP and LP, as e.g. [13,6] were based on the idea of adding equations 
to LP languages. This approach is appealing because equational logic is simple, 
well-known and widely applicable. Equational logic captures LP by representing 
Horn clauses as a particular kind of conditional equations, and it seems to capture 
also FP by viewing functional programs as sets of oriented equations, also known 

* This research has been partially supported by the Spanish National Project TIC98- 
0445-C03-02 ‘TREND” and the Esprit BRA Working Group EP-22457 “CCLII” . 
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as . (shortly, TRSs) [3]. Certainly, term rewriting serves 

as an operational model for FP, but in spite of this equational logic does not 
provide a logic semantics for FP programs. In general, the set of all equations 
that are logical consequences of a functional program in equational logic 
characterize the meaning of the program. As a simple example, let V be the FP 
program consisting of the following two equations: 

repeatl(X) « [Xlrepeatl(X)] repeat2(X) « [X,X|repeat2(X)] 

Here [X I Xs] is intended to represent a list with head X and tail Xs, and the no- 
tation [X,X|repeat2(X)] is meant as an abbreviation for [X| [X|repeat2(X)]] . 
In a non-strict FP language, it is understood that the two expressions 
repeatl(O) and repeat2(0) have the same meaning, namely an infinite list 
formed by repeated occurrences of 0. If equational logic would characterize 
the meaning of V, both expressions should be interchangeable for the pur- 
poses of equational deduction, which is not the case. In particular, the equation 
repeatl(O) = repeat2(0) cannot be deduced from V in equational logic. 

Borrowing ideas from denotational semantics, [8] proposed a rewriting logic 
CRWL to characterize the logical meaning of higher-order FP and FLP pro- 
grams. The main results in [8] are existence of least Herbrand models for all 
programs, in analogy to the LP case, as well as soundness and completeness of 
a lazy narrowing calculus CLNC for goal solving. No type discipline was consid- 
ered. 

Most functional languages use Milner’s type system [14], which helps to avoid 
errors and to write more readable programs. This system has two crucial proper- 
ties. Firstly, “well-typed programs don’t go wrong”, i.e., it is guaranteed that no 
type errors will occur during program execution, without any need of dynamic 
type checking. Secondly, types are polymorphic, because they include type vari- 
ables with a universal reading, standing for any type. For instance, a function 
to compute the length of a list admits the polymorphic type [a] int, mean- 
ing that it will work for a list of values of any type a. Polymorphism promotes 
genericity of programs. 

Type discipline in LP is not as well understood as in FP. Often one finds a 
distinction between the so-called and . . views of types. The 

descriptive approach is applied to originally untyped programs, and views types 
as approximations (usually regular supersets) of the success sets of 
predicates. On the contrary, the prescriptive approach views types . as 

imposing a restriction to the semantics of a program, so that predicates only 
accept arguments of the prescribed types. Usually, the prescriptive view leads to 
explicit type annotations in programs. See [18] for more details on type systems 
for LP. 

In our opinion, polymorphic type systems in Milner’s style are also a good choice 
for LP and FLP languages. In the past, polymorphic type systems have been 
proposed for Prolog programs [15,10], for equational logic programs [11] and for 
higher-order logic programs in the language A-Prolog [16]. Exactly as in Milner’s 
original system, [15] guarantees that well-typed programs don’t go wrong without 
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any type checking at run time. On the contrary, the type systems in [10,11,16] 
can accept a wider class of well-typed programs, but type annotations at run 
time are needed. 

Polymorphic type systems are implemented in some FLP languages, such as 
Curry [12] and TOy [4]. Currently, TOy performs no dynamic type checking. 
As a consequence, absence of type errors at run time is guaranteed for purely 
functional computations, but not for more complicated computations involving 
HO variables. This paper is intended as a contribution to a better understanding 
of polymorphic type discipline in FLP languages. Starting from the results in 
[8], we will extend the rewriting logic CRWL and the narrowing calculus CLNC 
with a polymorphic type system, and we will investigate the consequences of type 
discipline both at the semantic level and at the operational level. At the semantic 
level, we will modify the models from [8] to incorporate a type universe. At the 
operational level, we will modify CLNC to maintain type information in goals. 
The modified narrowing calculus will be sound and complete in a reasonable 
sense w.r.t. the computation of well-typed solutions. Moreover, dynamic type 
checking will take place only at those computation steps where some HO logic 
variable becomes bound. 

The rest of the paper is organized as follows. In Section 2 we introduce Higher- 
Order (shortly, HO) FLP programs as a special kind of applicative TRSs, as 
well as a polymorphic type system. In Sections 3 and 4 we present the results 
concerning logical semantics and goal solving, respectively, and in Section 5 we 
summarize our conclusions. Due to lack of space, we have given only short proof 
hints. Detailed proofs will appear in an extended version of the paper. 



2 Programming with Applicative Rewrite Systems 

2.1 Types and Expressions 

Since we are interested in HO FLP languages with a type discipline, we need 
a suitable syntax to represent types and expressions of any type. To introduce 
types, we assume a countable set TVar of a, (3, .. . and a count- 
able ranked alphabet TC = C. t £ Type 

are built as t ::= a (a £ TVar) | C ri . . . r„ {C £ TC^) | r ^ t'. 

Types without any occurrence of ^ are called . By convention, C Tn 

abbreviates C ri . . . r„, associates to the right, and Tn ^ t abbreviates 
Ti ^ ^ Tn ^ T. The set of type variables occurring in t is written tvar^r). 

A type r is called iff tvar{r) = 0, and , . otherwise. The 

type variables occurring in polymorphic types have an implicit universal reading. 
A over TC is a triple S = {TC, DC, FS), where DC = 

resp. FS = ranked sets of resp. 

. Moreover, each c £ DC^ comes with a type declaration 
c :: Tn ^ C ctk, where n, k>0, a\,. . . , au are pairwise different, Ti are datatypes, 
and tvar(ri) C {ai,. . . , a^} for all 1 < i < n (so-called ). 
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Also, every / S FS"' comes with a type declaration f Tn ^ t, where Tj, r are 
arbitrary types. 

In the sequel, we will use the notation h :: t €var F to indicate that S includes 
the type declaration /i :: t up to a renaming of type variables. For any signature 
E, we write for the result of extending E with a new data constructor 
_L :: a, intended to represent an undefined value that belongs to every type. As 
notational conventions, we use c, c? G DC, f,g G FS and h G DC U FS, and 
we define the of ft- G DC^ U FS'” as ar{h) = n. In the sequel, we always 
suppose a given signature E, that will not appear explicitely in our notation. 
Assuming a countable set DVar of data X,Y,... (disjoint with TVar), 

e G Exp± are defined as follows: 
e ::= A (A G DVar) | _L | ft (ft G CS U FS) | (e d) 

These expressions are usually called , because (e ei) stands for the 

operation (represented as juxtaposition) which applies the function 
denoted by e to the argument denoted by ei. FO expressions can be translated 
to applicative expressions by means of so-called . For instance, 

f{X,g{Y)) becomes (/ A {g A)). The set of data variables occurring in e is 
written var{e). An expression e is called iff var(e) = 0, and other- 

wise. Following a usual convention, we assume that application associates to the 
left, and we use the notation e e„ to abbreviate e Ci . . . e„. Expressions e G Exp 
without occurrences of T are called . Two important subclasses of expres- 
sions are t G Term±, defined as 

t ::= A (A G DVar) | T | (c t„) (c G CF”) 
and t G Pat±, defined as: 

t ::= X (A GDVar) \ T | (ctm) {cGDC^, m<n) \ (ftm) (/ GFF”, m<n) 
t G Term and t G Pat are defined analogously, 

but omitting T. Note that Term± C Pat± C Exp±. As usual in FP, data terms 
are used to represent data values. Patterns generalize data terms and can be used 
as an intensional representation of functions. Most functional languages allow 
also A of the form AA.e to represent functions. Some approaches to 

HO FTP also permit A-abstractions, see [19]. We will avoid them because they 
give rise to undecidable unification problems [7], and applicative expressions are 
expressive enough for most programming purposes. 

The next example illustrates some of the notions introduced so far. 

Let us consider a signature with 

TC^ = {bool,nat}, DC'^ = {true, false, z, nil}, DC^ = |s}, DC^ = {cons}, 
PS^ = {not,foo}, FF^ = { and, or, plus, map, snd, twice}, and with the fol- 
lowing type declarations: 

true, false : : bool z : : nat s : : nat ^ nat 

nil : : list a cons : : a — > list a — > list a 

not : : bool — > bool and, or : : bool — > bool ^ bool 

plus : : nat — > nat ^ nat foo : : a ^ nat 

map : : {a (3) ^ list a — > list f3 

snd : : a ^ (3 ^ a twice : : (a — > a) ^ a ^ a 
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Then, we can build such as (s X), (cons (s X) (cons Y nil)); 

such as (plus z), (snd X), (twice twice), (twice (plus X)); and 
, like (map (s X) (cons (s X) nil)), (twice (plus X) Y). 

In the sequel, we will use Prolog notation for the list constructors, writing [ ] 
for nil and [X|Xs] for cons X Xs. The following classification of expressions is 
useful: X Cm, with X e DVar and to > 0, is called a , while 

h Cm with h G DC U FS is called a . . . Moreover, a rigid expression 

is called iS h G FS and to > ar{h), and otherwise. Note that 

any pattern is either a variable or a passive rigid expression. As we will see in 
Section 3, outermost reduction makes sense only for active rigid expressions. 

Following the spirit of denotational semantics [20], we view Pat± as the set of 
finite elements of a semantic domain, and we define the 

C as the least partial ordering over Pat± satisfying the following properties: 
-L C t, for all t G Pat±; X O X, for all X G DVar; and h tm V h Sm whenever 
these two expressions are patterns and U C Si for all 1 < t < to. Pat±, and 
more generally any partially ordered set (shortly, poset), can be converted into 
a semantic domain by means of a technique called . ; see [9] for 

details. 

In the sequel we will need substitutions. We define at G TSub 

as mappings at : TV ar Type extended to at : Type Type in the natural 

way. Similarly, we consider ad G DSub± given by map- 
pings ad : DV ar ^ Pat±, ad G D Sub given by mappings 

ad : DVar Pat, and given as pairs cr = {at, ad)- By convention, 

we write rat instead of crt(r), and 6tat for the composition of 9t and at, such 
that T{9tat) = {T9t)at for any r. We define the dom{at) as the set of all 

type variables a s.t. at{a) yf a, and the ran{at) as Ua6dom(crt) tvar{at{a)). 
Similar notions can be defined for data substitutions. The . . 

id = {idt,idd) is such that idt{a) = a for all a G TV ar and idd{X) = X for 
all X G DVar. The approximation ordering over Pat± induces another approx- 
imation ordering over DSub±, defined by ad E iff ad{X) C X(t(j(A), for all 
X G DVar. Another useful ordering over DSub± is , defined by 

bd < 9'^ iff 9'^ = 9 dad for some ad G DSub±. For any set of variables X, we 
use the notations 9d < 9'^[X] (resp. 9d < 9'^[\X]) to indicate that X9'^ = X9dad 
holds for some ad G DSub± and all X G X (resp. all A ^ X). 

2.2 Well- Typed Expressions 

Following Milner’s type system [14], we will now introduce the notion of well- 
typed expression. We define an as any set T of type assump- 

tions X :: T for data variables, such that T does not include two different as- 
sumptions for the same variable. The dom{T) and the ran(T) of a 

type environment are the set of all data variables resp. type variables that occur 
in T. Given at G TSub, we define Tat = {X :: rat \ X :: r G T}. We write 
T' < T iff there is some at G TSub s.t. T' = Tat- T \- e :: t are 

derived by means of the following inference rules: 
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VRT1-X::r, ifX::rGT. 

ID T \~ h :: rat, if h :: t Gvar o't € TSub. 

AP T h (e ei) :: r, if T h e :: (ti ^ r) and T h d :: ti, for some t\. 

An expression e G Exp± is called in the type environment T iff there 

exists some type r s.t. T h e :: r. Expressions that admit more than one type 
in T are called , . .A well-typed expression always admits a so-called 

that is more general than any other. Adapting ideas from [14], we 
define a algorithm TR to compute principal types. Assume 

a expression e and a type environment T s.t. var(e) C dom{T). Then TR(T,e) 
returns a pair of the form (e"^, E) where is a of e and if is a 

system of equations between types, expressing most general conditions for r to 
be a valid type of e. The algorithm TR works by structural recursion on e: 

VR TR{T, X) = 0), if A :: r G T. 

ID TR{T, h) = 0), iih:: T Gvar is a fresh variant of ft-’s type declaration. 

AP TR{T, (e ei)) = E U El U {r « n ^ 7 }), 

if TR(T, e) = , E), TR(T, ei) = , El), tvar{E) n tvar{El) C ran(T), 

7 ^ tvar{E) U tvar{El) fresh type variable. 

, as those returned by TR, carry an obvious certifica- 
tion of their well- typed character. In particular, the annotations of their variables 
define an environment. Their syntactic specification is: 

e ::= {XGDVar,TGType) \ {h :: TGvarS±, atGTSub) \ 

Given a system E of equations between types, its set of TSol{E) con- 
sists of all at G TSub s.t. rat = r'at for all r « r' G E. If E is (i.e., 

TSol{E) 0), a most general solution mgu{E) = at G TSol{E) can by com- 
puted by means of Robinson’s unification algorithm (see e.g. [1]). The next result 
is easily proved by structural induction on e. 

Proposition!. TR{T,e) = {e^,E) at G TSol{E) 

Tat b e :: TCTt , T' < T T' h e^' , 

atGTSol(E) , , T' = Tat e^' . e^at □ 

Assuming TR{T,e) = {e^ ,E) with solvable E, and at = mgu{E), we will write 
PT{T,e) = rat for the of e w.r.t. T, and PA{e) = e^at for 

the . of e w.r.t. T. All the expressions from Example 

1 are well-typed in suitable environments, and some of them are polymorphic. 
For instance, the pattern twice twice is well-typed in the empty environment. 
Moreover, EA(0, twice twice) can be computed as 

(twiceb“^“)^“^“)^(“^“)^“^“ twice(“^“)^“^“) 

To compute a principal type for an expression e with var{e) = {Ai, . . . , A„} one 
can invoke TR(T, e) with T = {Ai :: a\, . . . , A„ :: oi}, where at are n pairwise 
different type variables. 

Due to the transparency property required for the type declarations of data 
constructors, all data terms t are in the sense that the type of the 

variables occurring in t can be deduced from the type of t. It is useful to isolate 
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those patterns that have a similar property. We say that a pattern t is 
iff for each subpattern of t of the form / tm, the type declared for f in S can 
be written as Tm t with tvarijm) C tvar{T). Note that the pattern snd X is 
not transparent. In fact, its principal type j3 ^ (3 gives no information on the 
type of X. 

2.3 Programs 

Following [8], we define CRWL programs as a special kind of applicative TRSs, 
but now requiring well-typedness. More precisely, assuming f G FS'^ whose 
declared type (up to renaming of type variables) is of the form / :: r„ ^ r, a 
defining rule for / must have the following form: 




left hand side (1) Hght hand side Condition Type Environment 

where I must be linear, ti must be transparent patterns, r must be an expression 
s.t. var{r) C var{l), the condition C must consist of finitely many (possibly zero) 
so-called a M 5 where a, b are expressions, and T must be 

a type environment whose domain is the set of all data variables occurring in 
the rewrite rule, and such that: T \- ti :: Ti for l<i<n, Thr::T and 
T \- C :: bool. The symbol _L never occurs in a defining rule. A 
CRWL program can be any set of defining rules for different symbols 

f G FS. Neither termination nor confluence is required. In particular, the lack of 
confluence means that CRWL programs can define non-deterministic functions, 
whose usefulness for FLP languages has been defended in [9] . 

The meaning of joinability statements will be explained in the next section. 
An additional explanation is needed to understand the previous definitions. In 
T \- C :: bool, we view C as an “expression” built from symbols in the current 
signature X, plus the two additional operations (M) :: a ^ a ^ bool and (,) 

: : bool ^ bool — > bool, used in infix notation to build conditions. We also 
agree to view the rewrite symbol as an operation (^) :: a a ^ bool, used 
in infix notation to build “expressions” I —>■ r. This convention will be useful for 
typing purposes in Section 4. 

Note that defining rules in a well-typed program are and 

, in the sense left-hand sides use transparent patterns and have exactly the 
principal type declared for the corresponding function. Transparency of function 
definitions made no sense in [8], but it is important in a typed setting. 

We consider also programs, which are sets of untyped defining rules 

where the type environment T is missing. Given an untyped program V, the 
type reconstruction algorithm TR can be used to decide whether it is possible 
to well-type the program by adding suitable type environments T to its rewrite 
rules. In practice, the user of FP languages such as Haskell [17] or FLP languages 
such as Toy [4] must provide type declarations only for data constructors. 
Next we show a well- typed program, using the signature from Example 1, that 
will be useful for other examples in the rest of the paper. 
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Well-typed program 

not : : bool — > bool 
not false true <;= 0 □ 0 
not true ^ false <;= 0 □ 0 

plus : : nat — > nat ^ nat 
plus z Y— ^Y4=0n{Y:: nat} 
plus (s X) Y s (plus X Y) 4= 0 □ {X, Y : : nat} 

foo :: a — > nat 

foo X ^ z F Y IXI X □ {X :: a, Y :: /3, F ^ a} 

map :: {a ^ P) ^ [a] ^ [/?] 

map F []^[]<J= 0n{F::a^/3} 

map F [X I Xs] ^ [F X I map F Xs] 0 □ {F :: a ^ /?, X :: a, Xs :: [a]} 
twice :: (a ^ a) ^ a ^ a 

twice F X F (F X) 0 □ {F :: a ^ a, X :: a} 

In this particular example, all patterns in the left-hand sides are data terms of 
FO type. See [8] for another example where HO patterns are used to represent 
logical circuits. 

3 A Rewriting Logic for Program Semantics 

In [8], a rewriting logic was proposed to deduce from an untyped CRWL pro- 
gram V certain statements that characterize the meaning of V. More precisely, 
two kinds of statements must be considered: e ^ t, 

meaning that t G Pat± approximates the value of e G Exp±; and . . 

a N 6, meaning that a ^ t, b ^ t holds for some t G Pat. The 
collection of all t s.t. e ^ t can be deduced from V leads to a logical charac- 
terization of e’s meaning. On the other hand, joinability statements are needed 
for conditions in rewrite rules, as well as for goals (see Section 4). They do not 
behave as equations in equational logic, for two reasons: t is required to be a 
total pattern rather than an arbitrary expression, and it is not required to be 
unique. Requiring unicity of t would lead to a deterministic version of joinability, 
which has been used under the name in several FTP languages. 

Roughly, a deduction of e ^ t in CRWL corresponds to a finite sequence of 
rewrite steps going from e to t in the TRS V U {X T}. Unfortunately, this 
simple idea does not work directly, because it leads to an unconvenient treatment 
of non-determinism. Therefore, a Goal-Oriented Rewriting Calculus (GORC for 
short) with special inference rules was given in [8] to formalize CRWL deducibil- 
ity. We recall this calculus below. The inference rule (OR) uses the set of (possi- 
bly partial) instances of rewrite rules from V, that is defined as follows, ignoring 
the type environments: 



snd :: a ^ P ^ P 

snd X Y Y -<= 0 □ {X :: a, Y :: /?} 



[P]± = {(1 ^ r ^ C)ad I (1 ^ r ^ C □ T)g (Td G DSub^} 




Semantics and Types in Functional Logic Programming 



9 



BT: e -> _L RR: X -> X, if X e DVar 



OR: 



ei > ti . . . 0 ^ > in C r a 1 . . . 3/7^ > t 

f ei . . . 077 a 1 . . • 3777 : t 

if t ^ _L is a pattern, m > 0, and f ti . . . tT, ^ r C £ \P\± 



DC: 



Cl > tl . . . 677 > t77 

h ei . . . e,7 h ti . . . t7i 

if h tl . . . t 7 i is a rigid pattern 



JN: 



a ^ t b — > t 
a N b 

if t is a total pattern 



We use the notation P hooRC ^ to assert that the statement ip can be deduced 
from the program V by means of a GORC proof. More detailed explanations 
about a FO version of GORC can be found in [9]. Note that V \~gorc e ^ t 
corresponds to a purely functional computation reducing e to t. Although the 
GORC calculus does not care about types, dynamic type checking is not needed 
for purely functional computations in the case of a well-typed program. This is 
shown by the next type preservation theorem. A similar result for a FO FLP 
language has been given in [2] . 

Theorem 1. Type preservation by reduction 

V e € Exp± T € Type 

T T\~e::T t G Pat± . . P ^gorc e — > t 

T^t::r 

Proof idea: Induction on the structure of the GORC proof that proves 
T ^GORG e ^ t. A case distinction is needed according to the GORC infer- 
ence rule applied at the last step. The (OR) case is the most interesting one; it 
uses type generality and transparency of the defining rules in P. □ 

To show that the previous theorem may fail if defining rules are not transparent, 
consider a function unpack : : (f3 P) a, defined by the non-transparent 
rewrite rule unpack (snd X) — > X <1= 0 □ {X : : a}. Then, taking the empty 
environment for T, we see that 

T F unpack (snd z) : : a P \~gorg unpack (snd z) ^ z 
but not T \- z : :a, thus violating type preservation. 

In Section 4 we will see that dynamic type checking is needed for solving goals 
that involve HO logic variables. There, the following notion will be useful. A 
GORC proof is obtained from a given GORC proof U by at- 
taching a type annotation to all the expressions occurring in 77 in a consistent 
way. More precisely, each approximation statement e t occurring in 77 must 
be annotated to become e'^ —>■ P for some type r; and each step in 77 where a 
joinability statement a ixi 6 is infered from premises a t and b t hy means 
of (JN), must be annotated to become an inference of a'^ ixi b'^ from P 

and P ^ P, for some type t. As seen in Subsection 2.2, only well- typed expres- 
sions can be type-annotated. Therefore, type-annotated GORC proofs always 
represent a well-typed computation. Some GORC proofs, however, cannot be 
type-annotated. Considering the well-typed program P from Example 2, we can 
show: 
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A GORC proof that 

1. foo true 1X1 z 

2. foo true ^ z 

3. plus z true IXI true 

4. plus z true ^ true 

5. z ^ z 

6. true ^ true 



be type-annotated. 

by (JN), 2, 5 and z total pattern 
by (OR), 6, 5, 3 
by (JN), 4, 6 and true total pattern 
by (OR), 5, 6 
by (DC) 
by (DC) 



Note that foo true ^ z is type preserving as a functional reduction. The prob- 
lem with the GORC proof above is that the GORC rule (OR) has guessed an 
ill-typed binding for the HO variable F. 

Models for CRWL programs have been presented in [8] for an untyped HO lan- 
guage, and in [2] for a typed FO language with algebraic datatypes. It is possible 
to combine both approaches, using A with a poset D-^ as data 

universe and a set as type universe. The elements in D-^ can be interpreted 
as intensional representations of functions by means of an application operation, 
although they are not true functions. Thanks to intensional semantics, one can 
work in a HO language while avoiding undecidability problems, especially unde- 
cidability of HO unification [7]. Variants of this idea have occured previously in 
some LP and equational LP languages, as e.g. in [5,10,11]. 

In particular, for any program V and any type environment T with dom(T) = 
DV ar, we can define a Ai-p{T) whose data universe is Pat± 

and whose type universe is Type, and we can prove that M-p{T) satisfies exactly 
those approximation and joinability statements p that are true in all the models 
of V under all possible totally defined valuations. Moreover, if V is well-typed, 
then Ai'p(T) is also well-typed in a natural sense. As a consequence of this result, 
GORC deducibility is sound and complete w.r.t. semantic validity. Moreover, 
M-p{T) can be viewed as the logical semantics of V, in analogy to the least 
Herbrand model of a LP program over a Herbrand universe with variables [1]. 
Least Herbrand models of FO CRWL programs can be also characterized as 
least fixpoints and free objects in a category of models [9,2]. These results can 
be extended to the present typed HO setting. 



4 A Lazy Narrowing Calculus for Goal Solving 



In this section we will extend the lazy narrowing calculus CLNC from [8] to 
prevent type errors at run time. All the examples used in the sequel implicitely 
refer to the we 11- typed program from Example 2. 

We recall that initial goals G for CLNC are finite systems of joinability state- 
ments a N 6. A correct solution for such a G is any total data substitution 
9d s.t. V \~GORC o£d bOd for all a M 6 G G. Soundness and completeness 
of CLNC, proved for untyped programs in [8], is also valid for well-typed pro- 
grams. In the typed setting, however, one would like to avoid the computation 
of ill-typed answers, whenever the program and the goal are well-typed. Unfor- 
tunately, there are problematic situations where run time type errors can occur 
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in CLNC. A first kind of problem appears when a HO logic variable F occurs 
as head in some flexible expression F em- In CLNC there are special trans- 
formations to guess a suitable pattern t as binding for F in such cases, and 
sometimes t Cm niay become ill-typed. For instance, the goal F X ixi Y, not Y 
1X1 X is well-typed, but the binding Fi-^plus z can lead to an ill-typed goal. As 
a second example, consider map F [true,X] M [Y.false] . This is also a well- 
typed goal, but CLNC can compute an ill-typed solution with bindings Fn^plus 
z, Xi-^false, Yi-^true. 

A second kind of problematic situation is related to statements h am ^ hhm, 
joining two . . expressions. In CLNC a . . transforma- 

tion reduces such condition to a system of simpler conditions M 6^. Assume 
that the declared type for h can be written as Tm t. Then we will say that 
the forementioned decomposition step is if tvarijm) C tvar^r), and 

otherwise. In the case of an opaque decomposition step, some of the new 
conditions Ui N bi may become ill- typed. Consider for instance the two well- typed 
goals snd true IXI snd z and snd (map not [ ] ) N snd (map s [ ] ) . Both 
of them become ill-typed after a decomposition step. In the first case the goal 
is unsolvable, while in the second case the computation ultimately succeeds, in 
spite of the type error. Opaque decomposition steps are also possible for approx- 
imation statements h Hm ^ htm- 

As shown in [10,11] for the case of FO typed SLD resolution and FO typed 
narrowing, respectively, a goal solving procedure that works with fully type- 
annotated goals can detect type errors at run time, since they cause failure at 
the level of type unification. Full type annotations have the disadventage that 
goal solving becomes more complex and less efficient also for those computations 
that do not need any dynamic type checking. Some optimization techniques were 
proposed in [10,11] to alleviate this difficulty. 

Here we will adopt a less costly solution to extend CLNC with dynamic type 
checking. Goals G will be similar to those from [8], but extended with a type 
environment T, and the notion of solution will be also extended so that solutions 
can provide bindings both for the data variables and for the type variables occur- 
ring in G. Moreover, those CLNC transformations that compute a binding t for 
some HO variable F will use type unification to ensure that t is type-compatible 
with the type expected for F in the goal type environment. The CLNC trans- 
formations not related to HO variable bindings will perform no dynamic type 
checking. In case of a computation that involves no HO logic variables, the only 
overhead w.r.t. untyped CLNC will consist in maintaining the goal type envi- 
ronment. This is not too costly, because it can be done on the basis of declared 
principal types, known at compilation time. 

In the rest of this section we develop these ideas and we state the soundness, 
completeness and type preservation properties of the resulting lazy narrowing 
calculus. Unfortunately, we have found no way to prevent dynamic type errors 
due to opaque decomposition. Therefore, our soundness theorem guarantees well- 
typed computations only under the assumption that no opaque decomposition 
steps have occurred. Dually, our completeness theorem only ensures the well- 
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typed computation of those solutions whose correctness is witnessed by some 
type-annotated GORC proof. 

4.1 Admissible Goals and Solutions 

The lazy narrowing calculus CLNC from [8] works with goals that include both 
joinability statements a ixi 6 to be solved and approximation statements e t 
to represent delayed unifications, introduced by lazy narrowing steps. Moreover, 
goals in G include a to represent the answer data substitution com- 
puted so far, and they satisfy a number of . . Here we must extend 

this class of goals, adding a and a second solved part to rep- 

resent an answer type substitution. Those variables of a goal that have been 
introduced locally by previous CLNC steps will be viewed as . . . For 

technical convenience, in the rest of the paper we assume a countable set EVar 
of existential data variables, and we use the notation (I ^ r ^ CaT) Gyar V 
to indicate that {I r ^ C nT) is a, renaming of some defining rule from V, 
using fresh type variables in T and fresh existential variables in place of data 
variables. We also write a ^ b for anyone of the conditions o M 6 or 6 M a. The 
formal definition of goal follows. More motivation and explanations can be found 
in [9]. 

Definition 1. Admissible goals G = PnCnSdnStnT 



delayed part P = ei ^ ti, . . . ,Ck ^ tk . 

6i G Exp ti G Pat produced data variables 

G pvar{P) = var{ti) U . . . U var{tk) production 

relation var{G) X Y 

I < i < k X G var(ei) Y G var{ti) 

unsolved part C = oi N 6i, . . . ,a/ M 5/ 

demanded data variables G 
ddvar{G) = {X G DV ar | A e™ ixi 6 € C, for some e^, b} 
data solved part Sd = {Xi « si, . . . , A„ « s„} 

, Si G Pat , Xi 



G ad mgu{Sd) 



type solved part St = {oi s 


^ Ti , . . . , 0^777, ~ Tm\ 

n € Type , a^ 


G at mgu{St) 


F = {Al :: n, . . . , Afe :: Tfc} . 


type environment G 


G 


goal invariants 


LN (ti,...,tk). linear 


EX 


pvar{P) C EVar 


NC 




SL 


var{Sd) n pvar{P) 



□ 



Note that any admisible goal verifies {PuG)ad = {PuC) and Tat = T, because 
of the requirements in items 3. and 4. above. By convention, are of 

the form Go = 0nGn0n0nTo, and include no existential variables. 
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In what follows we use the type reconstruction algorithm TR explained in Sub- 
section 2.2. We say that a goal G = PuCuSduSt nTis well-typed iff there 
is some T' < T s.t. T' h (P,C) :: bool. In addition, G is called iff 

T itself can be taken as T' . Note that conditions of defining rules in well-typed 
programs, as defined in Subsection 2.3, are always well-typed and type-closed. 
More formally: 

Definition 2. G = PnGnSdU St uT 

well-typed TR{T,{P,G)) = , , 

TSol{E) yf 0 , mgu{E) = a't T = Ta't , G 

type-closed 

type-closure 

^ = P u G u Sd U \ u ' , TR{T,{P,G)) = {{-f°°\E) 

at = mgu{E U St) o’t , . □ 

Well- typed solutions for admissible goals, and GORC proofs witnessing their 
correctness, can be defined as follows: 



Definition 3. G = PaC a SdO St nT 

V 

answer G {R, 6) R 

0={9t,0d) 

dom{6t) n dom{at) = 0 dom{9d) H dom{ad) = 0 
X G dom{9d) \ pvar{P) , 9d{X) . 

Z G dom{R) , Z G ran{9d) \ dom{T) 

(R,9) G well-typed solution 9t G Sol{St) 

9d G Sol{Sd) V ^GORC {P □ G)9d {T9t U R) h T0 Sol{G) 

G 

witness (R,9) G Sol{G) . 

(e t)9d G P9d 
{{a M b)9d) G (G9d) 

G V type-annotated witness (i?, 0) G 

Sol{G) 




As part of the definition of well-typed solution, we have demanded {T9t U i?) h 
T9. This is intended to mean that U i?) h X9d r9t must hold for each 
X :: T € T. The role of the type environment R is to provide type assumptions 
for the new data variables introduced in ran{9d)- As we will see, R is always 
empty in the case of computed solutions. 
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4.2 Lazy Narrowing Calculus 

Now we are ready to extend the lazy narrowing calculus CLNC from [8] with 
dynamic type checking. We keep the CLNC denomitation. As in [8], the notation 
G H- G' means that G is transformed into G' in one step. The aim when using 
CLNC is to transform an.. Go = 0nGn0n0nTo into a 

G„ = 0 □ 0 □ □ S't □ T„, and the return (0, ((Jt, (Jd)) as computed 

answer. Trivially, (0, (cTj, (Jd)) is a solution of G„ in the sense of Definition 3. 
A sequence of transformation steps Gq IT . . . H- G„ going from an initial goal to 
a solved goal, is called CLNC and noted as Go H-* G„. 

Due to the convention that P and G are understood as multisets, CLNC assumes 
no particular for choosing the goal statement to be processed in 

the next step. For writing failure rules we use FAIL, representing an irreducible 
inconsistent goal. We also use some hopefully self-explaining abbreviations for 
tuples. In particular, elm bm stands for m new joinability statements a^ M bj, 
and similarly for approximation statements. Some CLNC rules use the notation 
“[ . . . ]” meaning an optional part of a goal, present only under certain conditions. 
Finally, some other rules (related to ) refer to the set svar{e) of those 

data variables that occur in e at some position outside the scope of evaluable 
function calls. Formally, svar(X) = {AT} for any data variable X; for a rigid and 
passive expression e = h Cm, svar(e) = Ufci svar{ei); and svar{e) = 0 in any 
other case. 



The CLNC Calculus 

Rules for the Unsolved Part 



Identity: (ID) 

P □ XixiX, CnSdnStOTH- PnCnSdnStOT 

• X ^ pvar(P). 

Decomposition: (DCl) 

P □ h amixih bm, C □ Sd □ St □ T H- P □ amixi bm, C □ Sd □ St □ T 

• h a,m, h bm rigid and passive. 

Binding & Decomposition: (BD) ^ (fc > o) 

P □ X 3k X s bk, C □ Sd □ St □ T H- (P □ 3k X bk, C □ Sd)crd, X « snS( □ Tcrt' 

• s G Pat; X ^ var(s); X ^ pvar(P); var(s) C pvar(P) = 0. * (jd = {X / s}. 

o k = 0 and S’* = St; or k> 0, s bk rigid and passive, and (j( = mgu(St, r « t') 
where X :: r G T, r' = PT(T, s). 

Imitation & Decomposition: (IM) ★ (fc > o) 

P O X 3k h 0m bk, C n Sd D St o T 

T (P □ Vm3k X 0m bk, C □ Sd)cTd, X « h Vm) □ (Vm :: rm,T)cTt' 

• h Cmbk rigid and passive; X^pvar(P); X^svar(h e^); Vm fresh existential vars; 

(BD) not applicable. * (7^ = {X / h Vm}- 

o k = 0 and S’t = St; or k > 0 and = mgu(St, r « t') where X :: r' G T, 
V.‘. T m ^ ^var X 
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Outer Narrowing: (NRl) (fc > o) 

P □ f en3k X b, C □ Sd □ St □ T H- ^ tn, P □ C', rak x b, C □ SdnStDT',T 

• (f ^ r ^ C’ □ T’)G„ar V 

Guess & Outer Narrowing: (GN) ★ ★ (fe > o) 

P □ X e<,ak X b, C □ Sd □ St □ T 

H- (eq Sq, P □ C', rak x b, C □ Sd)cTd, X « f tp □ S^ □ (T', T)crt' 

• q > 0; X ^ pvar(P); (f tpSq ^ r <1= C’ □ T’)e„ar V. * (jd = {X / f tp}. 

o 0 -j = mgu(St, t' k, Tq^ t) where (f :: Tp ^ Tq ^ r)Gyar X, X :: r' G T. 

Guess 8i Decomposition: (GD) -k ★ 

P □ X apixiY bq, C □ Sd □ St □ T 

H- (P □ Vm^p, apIXlWm-qb^C □ SdVd, X « h Vm_p, Y « h Wm_q □ S{ 

tH (Vm — p •• r^tn — p , Wtn_q .. T^^m — q t T)tJt 

• (p + q) > 0; X, Y ^ pvar(P); Vm-p, Wm-q fresh existential vars; (h Vm-pap), 

(h Wm-qbq) rigid andj^assive. = {X / h Vm-p, Y / h Wm-q} 

o cr't = mgu(St, t' « r'p t, t" ~ t" q t) where X :: t', Y :: r" G T, 

(h :: T'm-p t'p ^ r) = (h :: T"m-q r" q r)G„ar X. 

Conflict : (CFl) 

P □ h 3p ixi h' bq, C □ Sd □ St □ T H- FAIL 

• h yf h’ or p yf q; h Tip, h’ bq rigid and passive. 

Cycle : (GY) 

PnXixia.CnSdDStnT H- FAIL 

• X yf a and X G svar(a). 



The CLNC Calculus 

Rules for the Delayed Part 



Decomposition: (DC2) 

h h tm, P □ C □ Sd □ St □ T H- 6m -> tm, P □ C □ Sd □ St □ T 

• h 6m rigid and passive. 

Output Binding & Decomposition: (OB) -k (k >o) 

X 6k ^ h titiSk, P o C o Sd n St o T 

H- (ek ^ Sk, P □ C □ Sd)cTd, [ X « h tm ] □ S( □ Tcrt' 

• [ X ^ pvar(P) ]. * (7d = {X / h tm} 

o k = 0 and S’t = St; or k> 0 and (j( = mgu(St, r « r') where X :: t' G T, 
{V.'.Tm ^ T^Gvar X. 

Input Binding: (IB) 

t^X, PnCnSdDStnT H- (Pn C)crdn Sd □ St □ T 

• tG Pat. * (Td = {X / t}. 

Input Imitation: (IIM) 

h — > X, P □ C □ Sd □ StOT H- (em ^ V^, P □ C)crdn SdQ StD (Vm :: rm),T 

• hcm ^ Pat rigid and passive; X G ddvar(C); Vm fresh existential vars. 

*ad = {X/hVm} o (h :: m ^ '^')^var ^ 
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Elimination : (EL) 

e— >X, PnCnSdDStnTH- PnCnSdnStnT 

• X ^ var(P □ C). 

Outer Narrowing: (NR2) (fc > o) 

fen3k — > t, PnCnSdDStnT H- en ^ G, rak t, PnC',CnSdDStnT',T 

• (t^DVar or tGddvar(C)); (f ^ r <J= C’ □ T’)G„ar V. 

Output Guess Si Outer Narrowing: (OGN) ★ ★ (fe > o) 

X eq3k t, P □ C □ Sd □ St □ T 

H- (eq ^ Sq, rak 1, P □ C', C □ Sd)(Td, X « f tp □ S( □ (T', T)crt' 

• q > 0; X^pvar(P); (f tpSq r ^ C □ T’)G„ar V] t^DVar or teddvar(C). 

• CTd = {X / f tp}. 

o k = 0 and S’t = St; or k> 0 and (j( = mgu(St,r' K^Tq^r) where X :: r' G T, 

(f :: Tp > Tq > T)^yar 

Output Guess Si Decomposition: (OGD) -k ★ 

X 6q ^ Y, P □ C □ Sd □ St □ T 

H- (eq ^ Wq, P □ C □ Sd)ad, [ X V^] □ S( □ (Vp :: “p, Wq :: “q, T)<r(_ 

• q> 0; Y G ddvar(C); [ X ^ pvar(P) ]; Vp, Wq fresh existential vars; (h Vp W q) 

rigid and passive. * Cd = {X / (h Vp), Y / {hVp Wq)}. 

o (j[ = mgu{St, t' ~Tq^ T, t " « r) where (h :: Tp ^ Tq ^ t) Gvar Y, 

X :: t', Y :: t" G T. 

Conflict : (GF2) 

h 3p ^ h' tq, P □ C □ Sd □ St □ T H- FAIL 

• h ^ h’ or PT^q; h Op rigid and passive. 

In spite of their complex appearence, CLNC transformation rules are natural 
in the sense that they are designed to guess the shape of GORC derivations 
step by step. For instance, the transformations (NRl) and (GN) guess the 
shape of (OR) steps in GORC proofs. As a lazy narrowing calculus, CLNC 
emulates suspensions and sharing by means of the approximation statements in 
the delayed part of goals. This and other interesting features regarding occurs 
check and safe cases for eager variable elimination, have been discussed briefly 
in [8] and more widely in [9] for the FO untyped case. Here we will focus on the 
treatment of dynamic type checking. Each CLNC transformation has attached 
certain side conditions, labelled with the symbols •, * and o, that must be 
checked before applying the transformation to the current goal G. In particular, 
those CLNC transformations whose name is marked with ★ or ★'A', have a side 
condition of type o that performs dynamic type checking. In all such cases, the 
type stored in the goal type environment for some HO variable is compared to the 
type of a candidate binding by means of unification. In case of success, the type 
solved part of the goal is properly actualized. Moreover, the ★★ transformations 
must be applied to the type closure G of the current goal G, rather than to G 
itself, in the case that G is well-typed. Otherwise, it may happen that a type error 
is not detected. This caution is important because several CLNC transformations 
do not preserve type-closedness of goals, and the type environment in a type- 
closed goal bears more precise information in general. 
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Let us show the behaviour of CLNC by means ot two examples. The first one 
illustrates the opaque decomposition problem: a initially well-typed goal is even- 
tually solved, but some intermediate goals become ill-typed due to opaque de- 
composition steps. The part of the current goal that is transformed at each step 
has been underlined. 

Opaque decomposition: 

G = G = 0 □ snd (map s [ ]) ixi snd (map not [ ]) □ 0 □ 0 □ 0 \\~dci 

G' = 0 □ map s [ ] N map not [ ] □ 0 □ 0 □ 0 

s ^ FI, [ ] ^ [ ] □ [ ] M map not [ ] □ 0 □ 0 □ {FI :: «i ^ /3i} W-ib,dC 2 

0 □ [ ] 1X1 map not [ ] □ 0 □ 0 □ (FI :: a\ ^ /3i} 

not ^ F2, [] — > []□[] IXI []n0D0n 

{FI :: ai — > /3i, F2 :: a2 — > /32} ^^~ib,dC2 

0 □ [ ] IXI [ ] □ 0 □ 0 □ {FI :: ai /3i, F2 :: a2 /? 2 } H“dci 

0n0D0n0n {FI :: ai /3i, F2 :: «2 ^ /? 2 } = G/ = G/ 

Note that the intermediate goal G' is ill- typed, but the final goal G/ is well- 
typed again. The computed answer, restricted to the variables in the initial goal, 
is (0, id). This is a well-typed solution, but no type-annotated witness exists due 
to the opaque decomposition step. 

The second example illustrates the need of computing the type-closure of a 
well-typed goal before applying a ★★ transformation. The following GLNG 
derivation is wrong because this prescription has been not obeyed in the step 
from G2 to G3 by the transformation (GN). As a consequence, the ill- typed 
binding F 1-^ plus z for the HO variable F escapes dynamic type checking. 
Note that the side condition o in (GN) would forbid this binding if (GN) were 
applied to G2 instead of G2. 

Wrong application of (GN). 

The initial goal is Go = 0 □ foo true Nz □0n0n0H- nri 

Gi Gi = true ^ X □FYMX,zlxizn0n0n 
{X :: a,Y :: P,F :: P ^ a} Vtjb 

G 2 yf G 2 = 0 □ F Y IXI true . z ixi zn0n0n 
{X :: q;,Y :: /3,F :: /3 ^ a} H-gat 

G 3 = Y — > N □ N IXI true , z M z □ F « plus z □ a « nat, P « nat □ 
{X, Y, N :: nat, F :: nat ^ nat} W~ib 

G 4 = 0 □ Y IXI true, z IXI z □ F « plus z □ a « nat, P « nat □ 

{X, Y, N :: nat, F :: nat — ^ nat} W-bd,dci 

Gf = 0n0nF « plus z, Y « true □ a « nat, P « nat □ 

{X, Y, N :: nat, F :: nat ^ nat} 
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The computed answer, restricted to the variables of the initial goal, is again 
(0,t(i). This is in fact a well-typed solution, but the ill-typed intermediate steps 
in the previous CLNC derivation correspond to the GORC proof from Example 
3, that cannot be type-annotated. By guessing the binding F i— > not instead of 
F 1-^- plus z, itis possible to build a different CLNC derivation that computes 
the same solution while maintaining well-typed intermediate goals. 

4.3 Soundness and Completeness 

To finish our presentation of CLNC with dynamic type checking, we show sound- 
ness and completeness results relative to the computation of well-typed solutions, 
assuming well-typed programs and well-typed, type-closed initial goals. We use 
the notation Sol(G') Cg^, Sol{G), meaning that every well-typed solution of G' 
is identical to some well-typed solution of G, except for the bindings of existen- 
tial variables. Similarly, {R, 6) Gex Sol{G') means that some well-typed solution 
of G' is identical to {R, 9) except for the bindings of existential variables. 

Each CLNC transformation step is correct in the sense of the following lemma. 

Lemma 1. Correctness lemma 

G G V G Vttr G' , 

G' Sol{G') C^x Sol{G) 

G' 

Proof idea: Items (a) and (b) can be checked separately for each CLNC trans- 
formation. □ 

The next theorem guarantees the correctness of CLNC computed answers. 



Theorem 2. Soundness Theorem 



(T,a) 



Go 



(T,a) G Sol{Go) 

{T,a). 

{T, a) G ASol{Go) 

Proof idea: the theorem follows from Lemma 1, using induction on the length 
of CLNC computations. A similar technique can be found in [8,9] for the case of 
untyped programs. Since CLNC transformations work by guessing the shape of 
GORC steps, every CLNC derivation leads naturally to a GORC witness, that 
can be type-annotated as long as no opaque decomposition steps occur. □ 

Completeness of CLNC is proved with the help of a well-founded ordering for 
witnesses of solutions. Let ^ be the well-founded multiset ordering for multisets 
of natural numbers [3]. Then: 

Definition 4. Multiset ordering for witnesses 

M M' 

SM SM' 

size 

M<M ' . SM ^ SM' □ 
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The next lemma guarantees that CLNC transformations can be chosen to make 
progress according to a given solution witness, avoiding opaque decomposition 
steps if the witness is type-annotated. 

Lemma 2. Completeness lemma 

G V 

{R,0) e Sol{G) . M . 

G H-Tfl G' {R,6) Gex Sol{G') . , M'<M 

(R,0) G ASol{G) M 

G' M' 



Proof idea: Choose (TR) as a CLNC transformation suitable to guess the 

shape of the last inference step in one of the GORC proofs included in the given 
witness. □ 



Finally, we can prove that CLNC computed answers subsume all possible well- 
typed solutions: 

Theorem 3. Completeness Theorem 

Go V 

(R,0) G Sol{G) 

Go G„ , G„ = 0 □ 0 □ □ T 

o-d < 0d[dvar{Go)] at < 0t[tvar{Go)] 

{R,0) & ASol{Go) 



Proof idea: Starting with Go and (R,0) G SoI{Gq), Lemma 2 can be reiter- 
atedly applied until a goal G„ in solved form is reached. This will eventually 
happen, because <l is a well-founded ordering. The requested CLNC derivation 
is obtained in this way. Moreover, if the initially given witness is type-annotated, 
item (b) from Lemma 2 ensures that all the intermediate goals will be indeed 
well-typed. □ 

5 Conclusions 



We have presented a polymorphic type system that extends a previous approach 
to HO FLP, based on the rewriting logic CRWL [8]. Keeping a logical seman- 
tics even for the case of untyped programs, we have defined a natural class of 
well-typed programs, and we have extended both the models and the lazy nar- 
rowing calculus CLNC from [8] to take types into account. We have identified 
two possible sources of run-time type errors in CLNC computations, namely 
and . . We have 

proposed dynamic type checking mechanisms to prevent the second problem, 
causing only a small overhead in computations that involve no use of HO logic 
variables. CLNC with dynamic type checking remains sound and complete for 
the computation of well-typed solutions, as long as no opaque decomposition 
steps occur. 

Working out and testing an implementation of dynamic type checking in the 
Toy system [4] is obviously an interesting topic for future research. 




20 



J. C. Gonzalez-Moreno et al. 



References 

1. K.R. Apt, Logic Programming, In J. van Leeuwen (ed.), Handbook of Theoretical 
Computer Science, vol. B, Chapter 10, Elsevier and The MIT Press, pp. 493-574, 
1990. 

2. P. Arenas-Sanchez and M. Rodriguez-Artalejo, A Semantic Framework for Func- 
tional Logic Programming with Algebraic Polymorphic Types, Proc. Int. Joint 
Conference on Theory and Practice of Software Development (TAPSOFT’97), 
Lille, Springer LNCS 1214, pp. 453-464, 1997. 

3. F. Baader and T. Nipkow, Term Rewriting and All That, Cambridge University 
Press, 1998. 

4. R. Caballero-Roldan, F.J. Lopez-Fraguas and J. Sanchez-Hernandez, User’s 
Manual for TOy, Technical Report SIP 57/97, Dpto. de Sistemas In- 
formaticos y Programacion, Univ. Complutense de Madrid. System available at 
http : //mozart . sip.ucm.es/ incoming/toy .html. 

5. W. Chen, M. Kifer and D.S. Warren, HiLog: A Foundation for Higher-Order Logic 
Programming, Journal of Logic Programming 15, pp. 187-230, 1993. 

6. J.A. Goguen and J. Meseguer, Models and Equality for Logical Programming, 
Proc. TAPSOFT’87, Springer LNCS 250, pp. 1-22, 1987. 

7. W. Goldfarb, The Undecidability of the Second-Order Unihcation Problem, The- 
oretical Computer Science 13, pp. 225-230, 1981. 

8. J.C. Gonzalez-Moreno, M.T. Hortala- Gonzalez and M. Rodriguez-Artalejo, 
A Higher Order Rewriting Logic for Functional Logic Programming, Proc. Int. 
Conf. on Logic Programming, Leuven, the MIT Press, pp. 153-167, 1997. 

9. J.C. Gonzalez-Moreno, M.T. Hortala-Gonzalez, F.J. Lopez-Fraguas and 
M. Rodriguez-Artalejo, An Approach to Declarative Programming Based on a 
Rewriting Logic, Journal of Logic Programming 40(1), pp. 47-87, 1999. 

10. M. Hanus, Polymorphic Higher-Order Programming in Prolog, Proc. Int. Conf. on 
Logic Programming (ICLP’89), The MIT Press, pp. 382-397, 1989. 

11. M. Hanus, A Functional and Logic Language with Polymorphic Types, Proc. Int. 
Symp. on Design and implementation of Symbolic Computation Systems, Springer 
LNCS 429, pp. 215-224, 1990. 

12. M. Hanus (ed.), Curry: an Integrated Functional Logic Language, available at 
http://www-i2.informatik.rwth-aachen.de/ hanus/curry, 1998. 

13. J. Jaffar, J.L. Lassez and M.J. Maher, A Theory of Complete Logic Programs with 
Equality, Journal of Logic Programming (1), pp. 211-223, 1984. 

14. R. Milner, A Theory of Type Polymorphism in Programming, Journal of Computer 
and Systems Sciences, 17, pp. 348-375, 1978. 

15. A. Mycroft and R.A. O’Keefe, A Polymorphic Type System for Prolog. Artificial 
Intelligence 23, pp. 295-307, 1984. 

16. G. Nadathur and P. Pfenning, The Type System of a Higher-Order Logic Pro- 
gramming Language, In F. Pfenning (ed.). Types in Logic Programming, The MIT 
Press, pp. 245-283. 1992. 

17. J. Peterson, and K. Hammond (eds.). Report on the Programming Language 
Haskell, A Non-strict, Purely Functional Language, Version 1.4, April 7, 1997. 

18. F. Pfenning (ed.). Types in Logic Programming, The MIT Press. 1992. 

19. C. Prehofer, Solving Higher Order Equations: From Logic to Programming, 
Birkhauser, 1998. 

20. D.S. Scott, Domains for Denotational Semantics, Proc. ICALP’82, Springer LNCS 
140, pp. 577-613, 1982. 




Polytypic Programming With Ease 

(Extended Abstract) 



Ralf Hinze 

Institut fiir Informatik III, Universitat Bonn 
Romerstrafie 164, 53117 Bonn, Germany 
ralf Oinf ormat ik . uni-bonn . de 
http : //www. informatik.uni-bonn.de/~ralf/ 



Abstract. This paper proposes a new framework for a polytypic exten- 
sion of functional programming languages. A functional polytypic pro- 
gram is one that is parameterised by datatype. Since polytypic functions 
are dehned by induction on types rather than by induction on values, 
they typically operate on a higher level of abstraction than their mono- 
typic counterparts. However, polytypic programming is not necessarily 
more complicated than conventional programming. In fact, a polytypic 
function is uniquely defined by its action on constant functors, projection 
functors, sums, and products. This information is sufficient to specialize 
a polytypic function to arbitrary datatypes, including mutually recur- 
sive datatypes and nested datatypes. The key idea is to use infinite trees 
as index sets for polytypic functions and to interpret datatypes as alge- 
braic trees. This approach is simpler, more general, and more efficient 
than previous ones that are based on the initial algebra semantics of 
datatypes. 



1 Introduction 

This paper proposes a new framework for a polytypic extension of functional pro- 
gramming languages such as Haskell or Standard ML. A polytypic function is one 
that is defined by induction on the structure of types. The archetypical example 
of a polytypic function is j e :: / a — > / , which counts the number of values 
of type a in a given value of type / a. The function i e can sensibly be defined 
for each parameterised datatype and it is often — but not always — a tiresomely 
routine matter to do so. A polytypic programming language enables the user to 
program i e once and for all times. The specialization of i e to concrete in- 
stances of / is then handled automatically by the system. Polytypic programs are 
ubiquitous: typical examples include equality and comparison functions, map- 
ping functions, pretty printers (such as Haskell’s h function), parsers (such 
as Haskell’s ead function), data compression [9], and digital searching [6]. The 
ability to define such programs generically for all datatypes greatly simplifies 
the construction and maintenance of software systems. 

Since polytypic functions are defined by induction on types rather than by 
induction on values, they tend to be more abstract than their monotypic coun- 
terparts. However, once a certain familiarity has been gained, it turns out that 
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polytypic programming is actually simpler than conventional programming. To 
support this claim let us define two simple functions, i e and , for some 
illustrative datatypes. As a first example, consider the datatype of rose trees. ^ 

data R e a = B a ch a {Li {R e a)) 
data Li a = Ni \ C a {Li a) 

The size of a rose tree can be determined as follows [2]. 

ze :: R e a I 

i e {B a ch a ) = 1+ (a i e ) 

This definition is already quite sophisticated: it makes use of a general combining 
form and an auxiliary function. The use of a :: {a —f b) —f {Li a ^ Li &), 
however, also incurs a slight run-time penalty: a produces an intermediate 

list, which is immediately consumed by . This inefficiency can be eliminated 
by fusing o a i c into a single function (called i ef below) . 

ze :: R e a I 

i e {B a ch a ) = 1 -I- z e/ 

z e/ :: Li {R c a) ^ I 

i cf Ni =0 

i cf {C ) = i c + i cf 

Interestingly, this very definition naturally arises if we change the definition of 
rose trees to 



data R c' a = B a ch a {F c a) 

data F c a = Ni \ C {R c' a) {F c a) . 

The definition of proceeds completely analogously — it suffices, in fact, 
to replace ‘1’ by ‘a’ in the definitions above. 

A slightly more complex datatype is the type of perfect binary search trees. 

data Pc fee a = Ze a | 5 cc {Pc fee {N de a ) ) 
data N de a = N de a a 

The definition of Pe fee is somewhat unusual in that the recursive component, 
Pe fee {N de a ) , is not identical to the left-hand side of the equation: 

Pe fee is an example of a so-called nested datatype, a term coined by Bird and 
Meertens [4]. Since Pe fee only encompasses perfect binary search trees, the 
size of a tree of type Pe fee a a can be computed in logarithmic time. 

z e w Pe fee a — > / 

z e {Ze a) = 1 
ze (5cc)=2*ze -1-1 

^ Examples are given in the functional programming language Haskell 98 [21]. 
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The function i e counts the number of values of type a in a tree of type 
Pe fee a a. However, i e cannot be assigned the type Pe fee a a ^ I since 
the recursive call has type Pe fee {N de a ) ^ I . 

Summing up a perfect tree of integers is a bit more challenging. 

:: Pe fee I I ^ I 
{Ze a) = a 

{S cc ) = { e fee id ) 

v. N del I ^ I 
{N de ) = + + 

Here, e fee :: {a ^ a') ^ ') ^ {Pe fee a — > Pe fee a' ') denotes 

the mapping function of the binary functor Pe fee . Improving the efficiency of 
by fusing o e fee id is left as an exercise to the reader. 

Now, let us define i e and once and for all times. To this end we 
must first take a closer look at the structure of types. Reconsider the datatype 
definitions given above. Haskell’s data construct combines several features in a 
single coherent form: sums, products, and recursion. The structure of the types 
becomes more apparent if the definitions are rewritten as functor equations: 

R e = Id X Li ■ R e 
Li = K 1 + Id X Li 

Pe fee = F + Pe fee ■ {N de, S d) 

N de = F xS dx F , 

where KT is the constant functor. Id is the identity functor, F and S d are 
projection functors, and F ■ (Pi, . . . , P„) denotes the composition of an -ary 
functor P with functors, all of the same arity. Sum and product are defined 
pointwise: (Pi -I- P2) a = Pi a -I- P2 a and (Pi x P2) a = Pi a x P2 a. In essence, 
functor equations are written in a compositional or ‘point-free’ style while data 
definitions are written in an applicative or ‘pointwise’ style. We treat 1 , ‘-I-’, and 
‘x’ as if they were given by the following datatype declarations. 

data 1 =0 

data oi -I- 02 = / a\\ I «2 

data oi X 02 = ( ai , «2 ) 

To define z e it suffices to specify its action on constant functors, on the identity 
functor, on sums, and on products. Polytypic functions are written using angle 
brackets to distinguish them from ordinary functions. 

i e{f) :: \/a.f I 

i e{Id) = 1 

i e {K ) =0 

^ e(/i +/2) {I 1) = * e(/i) 1 

«e(/i-k/2)(/ 2)= * e(/2) 2 

^ e(/i X /2) (1,2) = * e(/i) 1 -k i e(/2) 



2 
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Each equation is more or less inevitable: a value of type Id a = a contains one 
element of type a; a value of type K a = contains no elements. To determine 
the size of an element of type /i a + f 2 a we must either calculate the size of a 
structure of type /i a or that of a structure of type /2 a. The size of a structure 
of type f I a X f 2 a is given by the sum of the size of the two components. From 
this definition the following specializations can be automatically derived. 



eR e 


= i eR e\ (c 1) 




eR ei If {B a eh a ) 


= f a + i eLi 1 { i eR 


ei If) 


eLi 1 f Ni 


= 0 




eLi 1 f (^C a a ) 


= f a + i eLi 1 If a 




ePe fee 


= i ePe fee 2 (c 1, c 


1) 


ePe fee 2 {Ze a) 


= fi a 




ePe fee 2 {S cc ) 


= i ePe fee 2 ( * eN de2 


{lfl,ip 2 ),f 2 ) 


eN de2 {ipi,f2) {N de 


)= !fl +IP 2 +fl 





We postpone a detailed explanation of the specialization process until Section 3. 
For the moment it suffices to note that the different instances rigidly follow the 
structure of the respective datatypes. How do these functions relate to the hand- 
crafted definitions? Now, i eR e corresponds to the second, more efficient def- 
inition of j e : we have i e = i eR e\ {c 1) and i ef = i eLi \ i e . 
On the negative side, i ePe fee is a linear-time implementation as opposed to 
the logarithmic i e . In general, a ‘structure-strict’, polytypic function has at 
least a linear running time. So we cannot reasonably expect to achieve the effi- 
ciency of a handcrafted implementation that exploits data-structural invariants. 

The polytypic definition of is equally simple. 



if) 


::// ^I 


{Id) 


= 


{K ) 


= 0 


(/1+/2) (/ 


1) = ifl) 1 


(/1+/2) {I 


2) = (/2) 2 


ifl X /2) ( 1, 


2) = ifl) 1 + 



Specializing (/) to the various datatypes yields definitions similar to those 
obtained for i e{f). In this case the generated functions are as efficient as the 
best handcoded implementations. 

The moral of the story so far: giving ad-hoc definitions of polytypic functions 
like i e and is sometimes simple and sometimes involving. While the poly- 
typic definition is slightly more abstract, it is also to a high degree inevitable. It 
is this feature that makes polytypic programming light and sweet. 

The rest of this paper is organized as follows. Section 2 introduces the basic 
ingredients of polytypic programming: functor equations and algebraic trees. 
Section 3 explains how to specialize a polytypic function to concrete instances 
of datatypes. Section 4 presents several examples of polytypic functions, among 
others polytypic reduction and polytypic equality. Finally, Section 5 reviews 
related work and points out directions for future work. 
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2 Datatypes as Algebraic Trees 

In the introduction we have seen that functor equations capture the essence 
of datatype definitions. In general, a system of functor equations has the form 
fi = ei' . . fp = Cp where the fi are functor variables and the are functor 

expressions. Given a ranked set of primitive functors, E = U with E^ = 

{1,1 } and E^ = {+ , x } , the set of functor expressions of arity n is inductively 
defined as follows. 

F" ::= 7T” | T” | (F”,...,F^”) 

Here 7T" denotes the n-ary projection functor selecting the i-th component. For 
unary and binary projection functors we use the following more familiar names: 
Id = n\, F = III, S d = 77|. The expression F • (Fi, . . . , F^,) denotes the 
composition of a fc-ary functor F with functors Fi, all of arity n. We omit the 
parentheses when k = 1 and we write K T instead of F • () when fc = 0. Finally, 
we write Fi 0 F 2 instead of © • (Fi, F 2 ) for © € 

Each functor equation defines a unique infinite tree, whose inner nodes are 
labelled with primitive functors of arity ^ 1 and whose leaves are decorated with 
nullary functors and projection functors. Figure 1 displays the trees defined by 
the equations for R e and Pe fee given in the previous section. Note that 




Fig. 1. Types interpreted as infinite trees 



R e is interpreted by a rational tree while Fe fee denotes an algebraic tree. 
A rational tree is a possibly infinite tree that has only a finite number of subtrees. 
Algebraic trees are obtained as solutions of so-called algebraic equations, which 
are akin to functor equations. We will view infinite trees naively as a kind of 
‘infinite normal form’ of functor expressions. Expressions in normal form are 
formed according to the following grammar. 

T" ::=7T” I F^-.(Tf,...,T,") 

Thus, P ■ {Fi, ... ,Fk) with P G E^ corresponds to a tree, whose root is labelled 
with P and which has subtrees Fi, . . . , F^, and 7T" corresponds to a leaf. For a 
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more formal treatment the interested reader is referred to the full version of this 
paper [ 8 ]. Courcelle’s article [5] provides a more detailed survey on the theory 
of infinite trees. Briefly, the set of infinite trees constitutes an initial continuous 
algebra. Systems of functor equations have least solutions in this complete partial 
order. 

Roughly speaking, the infinite tree defined by a functor equation is obtained 
by unrolling the equation ad infinitum applying the following functorial laws. 



In the latter equation H is a tuple of functor expressions. Functor composition 
can be seen as a substitution operation on trees. Eq. (2) defines the substitution 
of a leaf by a tree; Eq. (3) formalizes the propagation of a substitution to the 
subtrees of a node. As an example, consider the unfolding of Pe fee : 

Pe fee 

= Pe fee ^ + Pe fee ■ (Pe fee i,S d) 

= Pe fee o + (A + Pe fee ■ {N de,S d)) ■ {Pe fee i,S d) 

= Pe fee q + (Pe fee ^ + Pe fee ■ {Pe fee 2 , S d)) 

= Pe fee q + (Pe fee 1 + (P + Pe fee ■ {N de, S d)) ■ {Pe fee 2 , S d)) 

= Pe fee q + (Pe fee ^ + {Pe fee 2 + Pe fee ■ {Pe fee 3 , S d))) 

... , 

where Pe fee 0 = A and Pe fee „_|_i = Pe fee nXS” dxPe fee „. The unfolding 
shows that Pe fee is the disjoint union of perfectly balanced trees of arbitrary 
height. 

The major difference to previous approaches to polytypic programming [10] 
lies in the use of infinite instead of finite trees as index sets for polytypic func- 
tions. In essence, this means that the class of all datatypes is itself modeled by 
a non-strict datatype as opposed to an inductive datatype. This change is not 
as problematic as one might think at first sight. Polytypic functions can still be 
recursively defined. Of course, to make things work the functions involved must 
be continuous. This condition is, however, trivially satisfied since the functions 
are programs in Haskell or Standard ML. 

Now, let us consider some examples of functors. A functor is called polynomial 
if it is represented by a finite tree. 



N de23 = F X S dx F + F x S dx F x S dx F 

The functor A is called the diagonal or square functor; N de23 is used below in 
the definition of 2-3 trees. 

A regular functor is one that is given by a rational tree. 



P-(i7i,...,7T„) =F 

JPi- {Fi,...,Fn) = Fi 

(P-(Gi,...,G„)) •H = P-(Gi •H,...,G„-H) 



( 1 ) 

( 2 ) 

( 3 ) 



A = Id X Id 



Bi ee = F + Bi ee x S d x Bi ee 
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The functor Bi ee models external, binary search trees. Further examples of 
regular functors are R e, Li , R e', and F e . 

The functor Pe fee is an example of a non-regular or nested functor, which 
is given by an algebraic tree. 

Se =Kl-\-Se -A + IdxSe -A 
Tee23 = F + T ee23 ■ {N de23 , S d) 

Okasaki [19] uses the functor Se as the basis for a sequence implementation 
with an efficient indexing operation. The functor T ee23 models 2-3 trees. The 
novelty of this definition is that the data-structural invariants of 2-3 trees — each 
interior node has two or three children and each path from the root to a leaf has 
the same length — are made manifest. 

The same functor can usually be defined in a variety of ways. Take, for 
instance, the two definitions of rose trees given in Section 1. 

R e = Id X Li ■ R e R e' = Id x F e 

Li = K1 + Id X Li F e =K1 + R e' x F e 

Both R e and R e' denote the same rational tree depicted in Figure 1. 

3 Polytypic Functions 

We have already seen two examples of polytypic functions. In general, a polytypic 
function that is parameterised by m-ary functors is given by the following data 
(think of the following as a prototype for polytypic definitions) . 

(/> :: r{f) 

i^i) = 77i 

(P-(/l,...,/fc))= p( (/i),..., ifk)) 

The type of (/) is specified by the type scheme r(/). Since / is an m-ary 
functor, ]j. must be specified for 1 ^ i ^ m. Furthermore, an equation spec- 
ifying p must be given for each primitive functor P G S. This information is 
sufficient to define a unique function (/) for each functor / [5] . Brieffy, an in- 
ductively defined function like (/) can be uniquely extended to a continuous 
function on infinite trees. 

The question we pursue in this section is how to derive specializations of 
(/) for given instances of /. The process of specialization is necessary since 
(/) cannot directly be implemented in languages such as Haskell or Stan- 
dard ML. The reason is simply that the type of depends on the first ar- 
gument, which is itself a type (or possibly, the encoding of a type). Even if we 
circumvented this problem by using encodings into a universal datatype [22] or 
by using dynamic types and a typecase [1], the result would be rather inefficient 
because would interpret its type argument at each stage of the recursion. 
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By specializing (/) for a given / we remove this interpretative layer. Thus, 
we can view the following as a very special instance of partial evaluation. 

Since types correspond to algebraic trees, which may have an infinite number 
of different subtrees, the specialization cannot be based on the structure of types. 
However, using functor equations algebraic trees can be finitely represented so 
the idea suggests itself to carry out the specialization on the representation 
of trees. The main challenge lies in the treatment of functor composition. As- 
sume, for instance, that an unary functor is defined in terms of a binary functor: 
F = B ■ (ci, 62). Now, if we want to specialize i e{F), how can we generate 
code for the right-hand side? The central idea is to define an auxiliary function 
i 62(5) that satisfies i e2{B) ( i e(ei), i e(e2)) = i e{B ■ (61,62)) for all 61 
and 62. That is, i 62(H) takes i e{e\) and i 6(62) as arguments and imple- 
ments i 6(H • (61, 62)). We have seen that functor composition corresponds to a 
substitution operation on trees. Using the function i 62(B) we imitate substi- 
tution on the function level. In general, we define, for each arity n, a polytypic 
function „(g) :: (r(gi), . . . ,r(g„)) ^ r{g ■ (gi , . . . ,g„)) satisfying 



nig) { (gi),---, (gn))= (g-{gi,...,gn)) . (4) 

Note the close correspondence between types and functions: g is an -ary functor 
sending gi, . . . , g„ to g-(gi , . . . , gn)', likewise ^(g) is an -ary function sending 
(51), •••, (gn) to (g ■ (gi,...,gn)). 

For primitive functors P G A" the function „ (P) is defined by „ (P) = 
p. The derivation of ^(g) for projection functors and for functor compo- 
sition is a nice example in program calculation and proceeds almost mechanically. 
We assume that = ( (gi ), . . . , (gn)) and reason: 

^{n,)ip= (7T, • (5 i,...,g„)) (4) 

= (ff.) • (2) 

Generalizing ( (gi), . . . , (gn)) to the tuple (ipi , . . . , (pn) we have calculated 

„(7Ti) ((/?i, . . . , pn) = <Pi- For functor composition we obtain 

„(/i- (hi,...,hk)) 

= ((/i- (/ii,...,/ifc)) • ( 5 i,..., 5 „)) ( 4 ) 

= {h-{hi-(gi,...,gn),---,hk-(gi,...,gn))) ( 3 ) 

= k(h) ( (hi- (gi,...,gn)),..., (/ife • (51, . . . , g„))) (4) 

= k(h) ( n(hi) n(hk) ¥>) ■ (4) 



Thus, for each arity n ^ 0 the polytypic function ^(g) is given by 
u(g) ■■ (T(gi),---,T(gn)) ^ r(g ■ (gi,...,gn)) 

ni^i) =7Ti 

n(P) = P 

„(/l- (/ll,...,/lfe)) = fc(/l)*( „(/ll),.... 



n(hk)) ■ 



Polytypic Programming With Ease 



29 



where tt^ is the t-th projection function and denotes n-ary 

composition defined by {ip * {ip \^ . . . , ipn)) a = ip {ipi a, . . . ,ipn a). Note that the 
Qi are m-ary functors while the hi have arity n. Furthermore, note that the 
definition of ^{g) is i d c i e he c e f f c e e i . On a 
more abstract level we can view „ as an interpretation of functor expressions: 
Ui is interpreted by TTi, P by p, and by 

It remains to define (/) in terms of mif)' 

if)= (/•(7Ji,...,7T„)) (1) 

= „(/)( (Pi),..., (P„)) (4) 

= mif) { nj ■ definition 

By now we have the necessary prerequisites at hand to define the specializa- 
tion of a polytypic function (/) for a given instance of /. The specialization 
works by transforming a system of functor equations that defines / into a system 
of function definitions that defines mif) - particular, recursion on the level 
of types is implemented by recursion on the function level. 



fi = ei 


kAh) = 


fci (ei) 


fp 


k^ifp) = 


kp i^p) 



Here ki is the arity of ft. The expression kii^i) is given by the inductive 
definition above, additionally setting kiifi) = -fi-ki, where -fi-ki is 
a new function symbol. Additionally, the defining equation for _/, ie _/ = 
_/_m ( , . . . , 77m )’ must be added. 

As an example, consider the datatype Pe fee of Section 1 . 

Pe fee = F -h Pe fee ■ {N de, S d) 

Note that i e+ = (v), where (v) is given by {ipi V ip2) {I i) = (fi i 
and {ipi V ip2) {I 2) = P2 2- Using this abbreviation the specialization of 
i 62(^6 fee ) proceeds as follows. 

i e2iP + Pe fee -{Nde,S d)) {ipi,(f2) 

= * e2(+) ( I e2(P ) {ipi,(f2), I e2{Pe fee ■ {N de,S d)) {ipi,ip2)) 

= i e2iP ){ipi,if2)^ i e2iPe fee -{Nde,S d)) {ipi,ip2) 

= ipiV i e2(Pe fee) { i e2(N de) {ipi,ip2),ip2) 

Using the original constructor names we obtain 

i ePe fee , :: (Va./i a ^ I ,Va./2 a ^ I ) 

^ (Va.Pe fee (/i a) (/2 a) ^ I ) 

i ePe fee 2 {ifi,ip2) {Ze a) = ipi a 

i ePe fee 2 {ipi,ip2) {S cc ) = i ePe fee 2 { i eN de2 {ipi,(f2),if2) 

Since i e{f) has the polymorphic type r(/) = Va./ a ^ I , the auxiliary func- 
tions i enig) take polymorphic functions to polymorphic functions. In other 
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words, i ePe fee 2 must be assigned a rank-2 type signature [15]. Unfortu- 
nately, the above definition passes neither the Hugs 98 [14] nor the GHC [20] 
type-checker though both accept rank-2 type signatures. The reason is that 
Haskell provides only a limited form of type constructor polymorphism. Con- 
sider the subexpression i eN de 2 {^ 1 ,^ 2 ) in the last equation. It has type 
Wa.N de {gi a) (52 o.) ^ I j which is not unifiable with the expected type 
ya.fi a ^ I . Since Haskell deliberately omits type abstractions from the lan- 
guage of types [13], we cannot instantiate /i to A ^ N de {g\ ) (52 )• 

Fortunately, there is a way out of this dilemma. We simply replace each applica- 
tion of the functor variables fi and /2 by a new type variable, ie fi a is replaced 
by land /2 a by 2 - 

z ePe fee 2 1 I ,2^1 ) ^ {Pe fee 1 2^1 ) 

This trick works for arbitrary type signatures and as a benevolent side effect the 
rank -2 type signature has turned into a standard rank -1 signature. 



4 Examples 



4.1 Polytypic a 

Categorically speaking, a functor is the combination of a type constructor and 
a mapping function, which describes the action of the functor on functions. The 
mapping function can be generically defined for all datatypes.^ 



/ « (/> 

/ a if) if 

where 



a (/> 

a (Id) 
a {K ) 

« (/ 1 +/ 2 ) {I 
« (/ 1 +/ 2 ) {I 
a (A X A) ( 1 , 



:: Va.V&.(a b) ^ {f a ^ f b) 
= a if ) 

:: f f b 
= P 

1 ) = / (a (A) 1 ) 

2 ) = I (a (A) 2 ) 

2 ) = ( a (A) 1 , a (A) 2 ) 



It is revealing to consider the typings of the subsidiary functions a „((?). 



a n{g) ■■ {gi a ^ gi b,. . . ,g„ a ^ gn b) 

{9 {91 a) ... { 9 n a) ^ g {gi b) . . . (^„ &)) 

Replacing gi a hy i and gi b hy i we obtain the typings of -ary mapping 
functions. And, in fact, a „(g) corresponds to the mapping function of the 
-ary functor g. Thus, to define / a (/) generically for all types mapping func- 
tions of functors of arbitrary arity are required. The good news is that the 
programmer need not take care of their definition. Instead, they are generated 
automatically. 

^ We assume that type variables appearing in type signatures are scoped, ie the type 
variables a and b in the signature of map{f) are not universally quantified but refer 
to the occurrences in fmap{f)’s signature. 
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4.2 Polytypic Reduction 

The functions i e and are instances of a more general concept, due to 
Meertens [16], termed reduction or crush. A reduction is a function of type 
f a ^ a that collapses a structure of values of type a into a single value of type 
a. To define a reduction two ingredients are required: a value e :: a and a binary 
operation :: a ^ a ^ a. Usually but not necessarily e is the neutral element 
of . 



ed ce{f) 
ed ce{f) e 
where ed{f) 
ed{Id) 
ed{K ) 
erf(/i+/ 2 ) (/ 
erf(/i+/ 2 ) (/ 
ed{fi X /a) ( 1, 



:: Va.a {a a) ^fa^a 

= ed{f) 

:: f a 



1) — ed{fi) 1 

2 ) = erf ( 72 ) 2 

2 ) = erf(/i) i‘ ‘ erf(/ 2 ) 2 



A number of useful functions can be defined in terms of erf ce(/) and / a (/), 
see Figure 2. Meertens [16], Jansson and Jeuring [12] give further applications. 



sum{f) :: 'in.{Num n) ^ f n ^ n 

sum{f) = reduce{f) 0 (+) 

and{f) :: / Bool — > Bool 

and{f) = reduce{f) True (A) 

minimumlj) :: y a. {Bounded a, Ord a) ^ f a —> a 
minimum (f) = reduce (f) maxBound min 



size if) 
size{f) 
all{f) 
all{f) p 



:: a.'in.{Num n) ^ f a ^ n 

= sumlj) o fmap{f) {const 1) 

:: Va.(a — > Bool) {f a ^ Bool) 
= and{f) ofmap{f) p 



flatten (f) 
flatten (f) 
data Tree a 
shape (/) 
shape (/) 



:: Va./ a — > List a 

= reduce (f) [] (4f) o f map {f) wrap where wrap a 
= Empty I Leaf a j Fork {Tree a) {Tree a) 

:: Va./ a — > Tree a 

= reduce (f) Empty Fork o f map (f) Leaf 



Fig. 2. Examples of reductions 



4.3 Polytypic Equality and Comparison 

The equality function is a nice example of a function that is indexed by a nullary 
functor. In Haskell it can be automatically derived for datatypes of first-order 



32 



Ralf Hinze 



kind and the following can be seen as a formalization of that process. We assume 
that a suitable equality function for I is predefined. 



e (/) 






e ( 1 ) 




= T e 


e {I ) 




= e I 


e (/1+/2) (/ 


1) {I 


1) = e (/i) 1 1 


e (/1+/2) (/ 


1) {I 


2) = Fa e 


e (/1+/2) (/ 


2) {I 


i) = Fa e 


e (/1+/2) (I 


2) {I 


2) = e (/2) 2 2 


e ifi X /2) ( 1, 


2) ( 1, 


2) = e (/i) 1 1 A e (/2) 2 2 



Varying the definition of e (/) slightly we can also realize Haskell’s c a e 
function, which determines the precise ordering of two elements. 



data O de i g = LT \ EQ \ GT 



c 


(/) 




:: f ^ f ^ 0 de 1 g 


c 


(1) 




= EQ 


c 


{I ) 




= c I 


c 


(/1+/2) (/ 


l){I 


1 ) = C ifl) 1 1 


c 


(/1+/2) {I 


l){I 


2) =lt 


c 


(/1+/2) {I 


2) {I 


1 ) = gt 


c 


(/1+/2) {I 


2) {I 


2) = C (/2) 2 2 


c 


ifl X / 2 ) ( 1 , 


2) ( 1) 


2) = case c (/i) 1 1 of 

{EQ c IJ2) 2 2 



5 Related and Future Work 

This paper can be regarded as a successor to my previous work on polytypic 
programming [7], where a similar approach using rational trees is presented. 
The major difference between the two frameworks lies in the treatment of functor 
composition. In the ‘rational tree approach’ functor composition is regarded as 
a function symbol, which implies that a polytypic definition must specify the 
action on g-(gi, . . . , gn) for each n ^ 1. Clearly, this cannot be done exhaustively. 
Furthermore, since the cases for functor composition are redundant, there is no 
guarantee that the polytypic function behaves the same on equal functors such 
as R e and R e' . Both problems disappear if we handle functor composition 
on the meta level generalizing rational trees to algebraic trees. 

The classic approach to polytypic programming as realized in the polytypic 
programming language extension PolyP [10] is based on the initial algebra se- 
mantics of datatypes. Here, functors are modeled by the following grammar. 

F = nB 

B = KT\F \S d\B + B\ Bx.B\F -B 

Recursive datatypes are modeled by fixpoints of associated base functors: the 
functor ^lB, which is known as a type functor, denotes the unary functor F 
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given as the least solution of the equation F a = B{a, F a). Polytypic functions 
are defined according to the above structure of types. In PolyP the polytypic 
function i e{f) is defined as follows — modulo change of notation. 



* e(/) 
i e{fib) 
b i e{b) 
b i e{K } 
b i e{F ) 
b i e{S d) 

b i e\bi + 62) {I 1) 

b i e(&i + 62) (d 2) 

b i e(&i X 62) ( 1, 2) 
b i e{f ■ b) 



\/a.f a ^ I 
ca a{fib) (& i e{b)) 

ya.bal 

0 

1 

b I e(&i) 1 
b I e(&2) 2 

b i e{bi) i + b i 6(62) 2 
(/) (/ a (/) (& * e(&)) ) 



The program is quite elaborate as compared to the one given in Section 1: it 
involves two general combining forms, ca a{f) and / a (/), and an auxiliary 
polytypic function, (/). The disadvantages of the initial algebra approach 
are fairly obvious. The above definition is redundant: we know that i e{f) is 
uniquely defined by its action on constant functors. Id, sums, and products. The 
definition is incomplete: i e{f) is only applicable to regular functors (recall that, 
for instance, Pe fee is not a regular functor). Furthermore, the regular functor 
may not depend on functors of arity ^ 2 since functor composition is only 
defined for unary functors. Finally, the definition exhibits a slight inefficiency: 
the combing form / a (/) produces an intermediate data structure, which is 
immediately consumed by (/). In other words, i e{R e) corresponds to 
the first, less efficient definition of i e . 

An obvious advantage of PolyP is that it allows to define general recursion 
schemes like cata- and anamorphisms [17]. As an example, the recursion scheme 
ca a{f), which is used in i e{f), is given by 



ca a{f) :: yaNb.{f a b ^ b) ^ {f a ^ b) 
ca a{fib) ip = (fio b a (b) id {ca a{pb) ip) o 

The operation (-)' (called F c Of in PolyP) maps a type functor to its base 
functor, ie F' = B for F = pB. The function :: f a ^ f a {f a) decomposes 
an element of type / a by unfolding one level of recursion. While the explicit 
treatment of type recursion is unnecessary for many applications — all polytypic 
functions of PolyLib [12] can be implemented in our framework, except, of course, 
cata- and anamorphisms — it is indispensable for others. The polytypic unifica- 
tion algorithm described by Jansson and Jeuring [11], for instance, requires a 
function that determines the immediate subterms of a term. A similar function 
appears in the article of Bird, de Moor, and Hoogendijk [3], who present a gen- 
eralization of the maximum segment sum problem. In both cases the recursive 
structure of a datatype must be known. Now, since our framework deals with 
type recursion on the meta level, one could feel tempted to conclude that we 
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cannot deal with such applications. It appears, however, that the availability of 
operations on types is an orthogonal design issue. Hence, nothing prevents us 
from incorporating the operator (-)' depicted above. Let us furthermore general- 
ize (-)' so that it maps an n-ary, regular functor to its associated (n-l- l)-ary base 
functor. Given two polytypic functions i y. f a\ . . . Un {f a\ . . . Un) ^ f a\ ■ ■ ■ an 
and :: / fli . . . a„ — > /' fli . . . (/ fli . . . a„) we can define cata- and anamor- 

phisms for functors of arbitrary arity. Here are the definitions for unary functors. 

ca a{f) :: ya.\/b.{f' a b ^ b) ^ {f a ^ b) 

ca a{f) (fi = if o b a (/') id {ca a(J) ip) o 

a a{f) :: Va.V6.(& f a b) ^ {b ^ f a) 

a a{f) ip = i o b a (/') id {a a{f) ip) o ip 

It is worth noting that the definition of the subsidiary function b a {b) proceeds 
as before. In particular, there is no need to consider functor composition or type 
functors. Furthermore, the base functor may be a nested functor. The function 
that collects the immediate subterms of a term can be defined as follows. 

be {)'■'■ Li 

be ( ) = a e {') o 

Directions for future work suggest themselves. In the full version of this 
paper [8] we show that polytypic functions satisfy fusion laws analogous to the 
fusion law for folds. The functorial properties of f a (/) and the fusion law 
for reductions [16] are, for instance, consequences of the polytypic fusion laws. 
It remains to broaden the approach to include exponentials and higher-order 
polymorphism [13]. Adapting the technique of Meijer and Hutton [18] the former 
extension should be fairly straightforward. Currently, the author is working on 
the latter extension so that polytypic functions can be defined generically for all 
datatypes expressible in Haskell. An application of polytypic programming to 
digital searching is described in a companion paper [6], where we show how to 
define tries and operations on tries generically for arbitrary datatypes of first- 
order kind. The central insight is that a trie can be considered as a type-indexed 
datatype, which adds an interesting new dimension to polytypic programming. 
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Abstract. This article presents a type system based on the Damas- 
Milner system[DM82], that supports overloading. Types of overloaded 
symbols are constrained polymorphic types. The work is related to 
Haskell type classes[Wad89,NP93,HH,JW96], System 0[0WW95] and 
other similar type systems[Kae88,Smi91,.]on94,DC09G]. Restrictions im- 
posed in these systems with respect to overloading are eliminated. User- 
defined global and local overloading is supported without restrictions. 
There is no need for declarations or annotations of any sort. No lan- 
guage construct is added in order to cope with overloading. The type 
system uses a context-dependent overloading policy, specified by a pred- 
icate used in a single inference rule. Overloading of functions defined over 
different type constructors is supported, as done with Haskell’s construc- 
tor classes. No monomorphism restriction is required in order to solve 
ambiguity problems. The system uses an open-world approach, in which 
new overloaded definitions can be introduced with types automatically 
reflecting the new definitions. The article also presents a type inference 
algorithm for the system, which is proved to be sound and to compute 
principal typings. 



1 Introduction 

The problems with the treatment of overloading in languages that provide (para- 
metric) polymorphism and type inference, such as SML[MTH89,Pau96] and 
Miranda[Tur85], have been discussed for example by Wadler and Blott[Wad89]. 
For instance, square x = x * x cannot be written in SML, the reason being 
that * is overloaded for integers and reals. Equality is treated in a special way in 
SML. For example, the type of function member, that tests membership in a list, 
namely ‘ 'a list -> ‘ ‘a -> bool, involves a special type variable ‘ 'a, con- 
strained so that its instances must admit equality. In Miranda, this type is not 
constrained in this way; applying member to lists whose elements are functions 
generates a run-time error. 

In Haskell [Pe97,Tho96], type classes[NP93,HH,JW96] allow overloaded sym- 
bols to have different meanings in contexts requiring different types. Type classes 
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represented a big step forward, in the direction of providing comprehensive sup- 
port for overloading, together with polymorphism and type inference. However, 
the following points can be viewed as disadvantages of type classes: 

1. Class declarations, as well as type annotations and type declarations, are not 
needed for the inference of types of overloaded symbols, as is shown in this 
paper. Thus, a programmer should not be obliged to make a class declaration 
or type annotation in order to specify the type of a given symbol (he may 
still write type annotations for documentation and other purposes). 

2. The declaration of type classes involves an issue which is separate from over- 
loading resolution: to group logically related names in the same construct. As 
pointed out by Odersky, Wadler and Wehr[OWW95], “eliminating class dec- 
larations means one needs no longer decide in advance which operations be- 
long together in a class. In many situations, this will be a positive advantage. 
For instance, if we’re dealing with pairs, we want only first and second 
grouped together, but if we’re dealing with triples, we will want third as 
well. As a further example, consider the difficulties that the Haskell design- 
ers had deciding how to group numeric operators into classes. This design is 
still argued: should + and * be in a ‘ring’ class?” . Grouping logically related 
symbols together in a language construct involves the definition of a struc- 
ture of program interfaces; this is intrinsic to modular software development, 
but overloading resolution is a separate issue. 

3. For unrelated definitions of the same name in a program, the programmer 
is forced to create a class declaration with the type of the overloaded name. 

4. For any new definition of any given overloaded name, either its type must 
be an instance of the type specified in its class declaration, or the class 
declaration must be modified. 

5. The use of classes in type annotations conflicts with data abstraction. If an 
implementation of (say) x is changed so that an overloaded symbol is no 
longer used, or a new overloaded symbol is used, the types of all symbols 
defined by using x may have to be modified. 

With respect to specific approaches in implementations[.J“''98,Jon98a]: 

6. Definitions of overloaded symbols must occur in global instance declara- 
tions, and overloading is thus restricted to definitions that occur at the 
outermost level. Local overloading (from bindings occurring inside lambda- 
abstractions) is not allowed. Local overloading allows a programmer to make 
definitions where appropriate; he is not forced to make global declarations 
just because symbols being defined happen to be overloaded. 

Local overloading also allows (as an option for a language designer) the use 
of symbols defined in an outer level, despite of redefinition in an inner level 
(with a distinct type). 

7. Haskell makes a few restrictions on the form of class and instance declara- 
tions, certainly with good reasons, a discussion of these being outside the 
scope of this paper (see [.lon95,.lJM97,.lon98b,Jon94]). 
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System 0[0WW95] is an improvement in relation to type classes with re- 
spect to items (1) to (5) above. ^ System O uses universally quantified types, 
with a constraint on the quantified variable that is a (possibly empty) set of 
bindings o :: a — *■ r, indicating that there must exist an overloaded operator 
o :: p —> (r[p/a]), for any instance p of a.^ Although System O was an impor- 
tant step towards the solution to the problem of providing type inference for a 
language that supports polymorphism and overloading without the need for class 
declarations, it did not provide a satisfactory solution. Significant limitations of 
System O are as follows. It supports only context-independent overloading. This 
means that constants cannot be overloaded, nor function symbols with types 
like, for example, read : String ^ a, even though they could be used in con- 
texts that resolve the overloading (e.g. read str == "foo"). The type systems 
presented in [Kae88,Snii91,DC096] also support only context-independent over- 
loading. System O requires explicit annotation of the type of each overloaded 
function symbol. Thus, there is no type inference for overloaded symbols. Sys- 
tem O requires all type constructors of the arguments of overloaded functions 
to be pairwise distinct. This restricts even more the set of types of definitions 
of an overloaded symbol (this restriction is also imposed in the earlier work of 
Kaes[Kae88]). System O only allows definitions of overloaded symbols at the 
outermost level (this restriction is also imposed in the works of Kaes[Kae88], 
Geoffrey Smith[Smi91] and Mark Jones[.Jon94]). 

2 Overview of System CT 

The type system presented in this article, called System CT, allows multiple 
occurrences of overloaded symbols in a typing context, each occurrence with 
a distinct type. Typings for overloaded symbols are introduced in the context 
after corresponding let-bindings for these symbols (which correspond to instance 
declarations in Haskell, and inst declarations in System O). The overloading 
policy determines whether or not a given type may be the type of an overloaded 
symbol in a given context. 

System CT uses context-dependent overloading. Overloading of constants 
is allowed. Consider let one = 1 in let one = 1.0 in . . . , for example (we as- 
sume that literals 0 , 1 etc. have type Int and literals oO . 0 , 1.0 etc. have type 
Float). After the let-bindings, the typing context, say Ik, contains the typings 
one : Int and one : Float. The type derived for one in context Ik is {one : a}. a, 
indicating a type for which there is a constant one of that type, in /{,. 

All other type systems use a different approach, as far as we know. The type 
of a given overloaded symbol is either selected among the set of typings for 
that symbol in the typing context (e.g. [Kae88,Smi91,0WW95,DC096]) or, for 
each overloaded symbol, a fixed typing is used, together with a set of predicates 

^ Although System O does not require class and instance declarations, type annota- 
tions are required in the definition of overloaded symbols. 

^ The notation cr[r/a] indicates the usual textual substitution. 
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(i.e. a set of available type instances) and a constraint elimination rule, for trans- 
forming constrained into unconstrained types (e.g. [NP93,Joii94,HHJW96]). 
With overloading and this context independent constraint elimination, some 
difficulties arise in detecting ambiguity. A simple example is expression g one 
in typing context Fg with typings one : Int, one : Float, g : Int ^ Int,g : 
Float — > Int. The ambiguity in this expression would not be detected with- 
out additional rules in the type system, as both Tg h one : Int and Tg h g : 
Int — > Int could be derived, obtaining Tg h g one : Int, or Tg h one : Float 
and Tg h g : Float ^ Int, obtaining again Tg h gone : Int. This is a known 
problem, ol c he e ce[Jon94]. To solve it, restrictions are imposed in order to 
detect ambiguity. 

For example, the type systems of Haskell and Hugs detect this error by means 
of the following restriction on the syntax of type expressions (called Restriction 
A for further reference): “If T r is a type, then tv{P) C tv{ry\ where P 
specifies a set of constraints, r is a simple type and tv gives the set of free 
type variables of its argument. Note that Restriction A must not consider in P 
type variables that are free in the typing context, so that, for example, gx is 
not considered ambiguous, in a context as Tg above but where x is a lambda- 
bound variable. In such a context, gx is well typed. Unfortunately, Restriction 
A prevents the use of expressions which are unambiguous. Consider for example 
Tf = {f : Int — > Float,! : Float — > Int, one : Int, one : Float}. Expression 
f one + 1 (in a context such as Tf) is a simple example of an unambiguous 
expression that cannot be written in Haskell, nor in Hugs[.Jon98a]. Consider: 



class Fab where f : :a -> b 
class 0 a where one : : a 
instance F Int Float where . . . 
instance F Float Int where . . . 
instance 0 Int where . . . 
instance 0 Float where . . . 
main = print (f one + (l::lnt)) 



In Hugs and GHC 3.02[.l+98], which allow multiple parameter type classes, type 
(F a b, 0 a) => b (which would be the type of f one) is considered ambiguous 
(characterizing an overloading that cannot be resolved in any context). 

Letting h be defined by h x = True, another example is h one, which has 
type Bool in System CT and is considered ambiguous in Haskell or Hugs. 

System CT adopts a novel approach in the basic rule, (VAR), which gives the 
type of an overloaded symbol as the least common generalisation of the types 
of this symbol in a typing context. As a natural consequence, instantiation and 
constraint elimination are controlled in rule (APPL), by the use of unification. 

For example, in To above (with typings one : Int and one : Float), type 
{one : a}, a is derived for one: Int and Float are considered as instances of this 
type, due to the possible substitutions for unifying a with types of one in Tq. 



Type Inference for Overloading 



41 



In Tf, typing f one : {f : a ^ /3, one : a}. (3 indicates that this expression 
works like an overloaded constant; it can be used in a context requiring either a 
value of type Int or Float. Again, this is due to the possible substitutions for 
unifying types in {f : a — > /3, one : a} with typings for f and one in Ff. 

In System CT, the type of any overloaded symbol is computed automatically 
from the types given by definitions of this symbol that are “visible in the relevant 
scope” (i.e. that occur in the relevant typing context). The programmer need not 
anticipate all possible definitions an overloaded symbol might have, something 
which is needed in order to specify a (least common generalisation) type T 
for this symbol in a class declaration (so that all definitions of this symbol 
have types that are instances of T). In System CT, a new definition is not 
necessarily an instance of the least common generalisation of types given by 
previous definitions. Instead, any new definition may imply the assignment of a 
more general type than that computed according to previous definitions (as if 
a class declaration, if it existed, was automatically modified to reflect the new 
definition). In this sense. System CT uses in fact an approach that is “more 
open” than that used with type classes in Haskell. 

System CT uses the predicate ambiguous for detection of ambiguous over- 
loading (see section 3). With the use of this predicate, expressions with the 
following types are not considered ambiguous: 

1. Types for which tv{P) C tv{T) yf 0, despite the fact that tv{P) % to(r). 
This is the case of example f one above. Another example is map f o map 
g, where the standard map function is overloaded to operate, for example, on 
lists and trees, and o is the function composition operator. 

2. Types for which P has type variables that occur free in the typing context, 
despite the fact that tv{P) C tn(r) = 0. This is the case of g x above (40). 

Constraints that apply to the type of e e' are only those that have type 
variables that occur free in the typing context (e.g. g x), or occur in the “un- 
constrained part” of the type of e e' (e.g. snd (True, one)). In examples for 
which a component of a value is selected, constraints may not apply to the 
type of the selected component. For example, f st (True, one) where one is over- 
loaded and fst selects the first component of a pair. In System CT, the type of 
f St (True, one) is Bool; it is considered ambiguous in Haskell or Hugs. 

Another related example (taken from the Haskell mailing list) follows. Sup- 
pose that function read is overloaded, having a type that would be written as 
Va. {read : String-^ (a. String)}. String ^ (a. String) in System CT, and 
consider: read2 s = let {(a, si) = read s; (b, s2) = read sljin (a,b). In 

System CT, the type of si is String, irrespective of whether functions fst 
and snd are used in this example instead of pattern-matching. 

System CT supports global and local overloading unrestrictively, without 
the need for declarations or annotations. Overloaded definitions can occur inside 
lambda-abstractions, and can use lambda-bound variables. No monomorphism 
restriction[Po97,.Jon94] is necessary in order to solve ambiguity problems. 

System CT also supports overloading of functions defined over different type 
constructors, as done with Haskell’s constructor classes [Jori95]. In System CT 



42 



Carlos Camarao and Lucflia Figueiredo 



this issue has been solely a matter of giving a more informative type, since 
the original system, without constructor variables, also supported overloading of 
functions defined over different type constructors. The modifications required in 
the original system, in order to give such more informative types for overloaded 
symbols defined over different type constructors, were very simple. 

For example. System CT allows the writing of reusable code that works 
for a variety of essentially similar bulk types (see [.Jon96]), in a simple way. 
Assuming singleton and union to be overloaded to operate on some bulk types 
(for example List and Queue), we can write: 



leaves (Leaf a) = singleton a 

leaves (Branch tl t2) = leaves tl 'union' leaves t2 



Type {singleton : a — > c a, union : c a — s- c a — > c a}. Tree a — > c a is infered 
for leaves. Due to being defined in terms of overloaded functions, function 
leaves works itself just like an overloaded function. Its constrained polymo- 
prhic type reflects this fact. In the type of leaves, c is a c c a tab e. 

System CT enables a clear separation between the issues of overloading res- 
olution and definition of the structure of program interfaces. The type inference 
algorithm for System CT is a revised and extended version of a type inference 
algorithm used for computing i ci a ai for core-ML[Mit96]. 

The rest of the paper is organized as follows. Section 3 introduces the type 
rules of our system. Section 4 presents the type inference algorithm and proves 
theorems of soundness and computation of principal types. Section 5 concludes. 

3 Type System 

We use a language similar to core-ML[Mil78,DM82,Mit88,Mit9G], but new over- 
loadings can be introduced in let-bindings. Recursive let-bindings are not con- 
sidered (since they can be replaced by a fix point operator). For simplicity, let- 
bindings do not introduce nested scopes. Thus: let x = ei in let y = e2 in e 
is viewed as in a form let jx = ei; y = e2} in e, with a list of declarations, 
as usually found in functional programming languages (in our system allowing 
X = y for the introduction of new overloadings). 

Meta-variables a and [3 are used for type variables. We include value con- 
structors {k G JC) and type constructors {C G C). For simplicity, term variables 
(x G X) are divided into two disjoint groups: let-bound (o G O) and lambda- 
bound (u G U). Meta-variable n denotes a set {oi : called a set of 

constraints. A value constructor is considered as a let-bound variable which has 
a closed type with an empty set of constraints, fixed in a global typing context. 
Each type constructor C in C t\ . . .Tn and each type variable a in a ti . . . r„ 
has an arity, which is the value of n. It is assumed that there is a function type 
constructor (—*■), which has arity 2 and is used in infix notation. A type variable 
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with an arity greater than zero is called a constructor variable. Meta- variable y 
is used to denote either a constructor variable or a type constructor. 

Figure 1 gives the syntax of pre-terms and types of System CT. 

A I g c e Fisa set of pairs x : tr. A let-bound variable can occur 
more than once in a typing context. A pair x : cr is called a * 5 / x; if 
{x : " is the set of typings for x in F, then F(x) = is the set 

of types of X in F. 

A e b i i (or simply substitution) is a function from type variables 
to simple types or type constructors, that differ from the identity function (id) 
only on finitely many variables. If cr is a type and S' is a substitution, then Sa 
denotes the type obtained by substituting S(a) for each occurrence of free type 
variable a in a. Similarly, for a typing context F, SF denotes {x : Sa \ x : a G 
F}, and for a set of constraints k, Sk denotes {o : Sr | o : t G k}. 

S|y stands for the restriction of S to type variables in V: S|v(a) is equal to 
S(a) if a G V, and to a otherwise. 

tv{a) stands for the set of free type variables of a; tv{n) and tx(F) are defined 
similarly, considering types in k and F, respectively. tv(ti, . . . ,tn) abbreviates 
tv{ti)U. . .Utv(tn)- For clarity, we sometimes drop the superscripts in, for exam- 
ple, {xi}*^^ '” and k.t, assuming then systematically that i ranges 

from 1 to n and j ranges from 1 to m (where m, n > 0). 

Types are modified, with respect to the type system of core-ML, to include 
constrained types. Typing formulas have the form F h e : (k.t, F'), where F' 
contains typings of let-bound variables used for checking satisfiability of con- 
straints in K (see description of sat below). 

Quantification is defined over constrained types. Type cr is c ed if tv{a) = 0. 
Renaming of bound variables in quantified types yield syntactically equal types. 

The restriction of a set of constraints k to a set of type variables V, denoted 
by k\y, is defined inductively as follows: 



The closure of restricting a set of constraints k to a set of type variables V, 
denoted by is defined as follows: 



Informally, «:|y is obtained from k by keeping only typings which have type 
variables that are in V. n\y keeps typings that have type variables in V or in 
any typing kept “earlier”, means (S'rt)|y. 

The intersection of a set of substitutions S, denoted by (Q S, is given by: 




0 



{o : t}\v = if tv(r) n ^ = 0 then 0 else {o : r} 
({o : rj U k')\v = {o : t}\v U k'\v 




k\v if tv{n\v) C V 
otherwise 



n{5} = 5 

Pi ({5} U S) = S'! v where V = {a \ S{a) = S' (a), and 5" = P §} 
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Terms 


e ::= x \ Xu. e\ e e' | let 0 = e in e' 




Simple Types 


T :■.= C Tl . . .Tn \ an. ..Tn 


{n > 0) 


Constrained Types 


A ;:= {Oi : n}. r 


(n > 0) 


Types 


a ;:= Voi. a 


(n > 0) 



Figure 1: Abstract Syntax of System CT 



The type rules are given in Figure 2. 

Overloading is controlled by predicate p, in rule (LET). In this rule “T, x : cr” 
is a notation for updating T with x : a, which requires p{u,r{x)).^ p{a,T) 
basically tests if tr is not unifiable with types in T : 



f {r — {x : cr'}) {x ■. a} li X & U and x : a' G F 

} T U {x : crj if a: € O and (p(cr, F{x)) holds, if F{x) yf 0) 



p{o : Voi- K. T, T) = 

unify{{T = r'l) fails, for each V/3j. k '. t' G T, 

where type variables in {oi} and {/3j| are renamed to be distinct 

Rule (VAR) assigns to a given symbol the least common generalisation of 
the types of this symbol in the given typing context. For overloading resolution, 
this contrasts with a type system that enables the type of an overloaded symbol 
to be any of a given set of types in a typing context. 

In System CT, instantiation is done on application, where substitution of 
type variables is determined by unification. The use of unification in rule (APPL) 
is a fundamental characteristic of the treatment of overloading in System CT. 
Unify{E^ V) is the standard algorithm for computing the most general unifying 
substitution for the set of type equations A[Rob65,Mit96], but considers that 
type variables in V are not unifiable (type variables in V are free type variables, 
originally introduced in types of lambda-bound variables) . For reasons of space, 
we do not present the (slightly modified) unification algorithm. 

Function pt, used in rule (VAR), uses function leg (for ea c ge e a - 

tat ) to give constrained types for overloaded symbols. In the construction of 
such types, pt renames term variables to fresh term variables, which are used only 
internally in the type system (i.e. they do not appear in programs). As an exam- 
ple where this renaming is needed, consider the types of e and e' in e e', where 
e = (let a; = ei in let a; = C 2 in 63 ) and e' = (let x = e} in let a; = 62 in 63 ). 
Without renaming, constraints on these types would both include typings for x. 

® Rule (LET) could be modified in order to allow overlapping declarations (for which 
p, as defined, gives false). In this case, there should exist a mechanism for choosing 
a default implementation (usually the most specific one) for overloading resolution, 
in cases where overloading should have been resolved. This facility is not discussed 
in this paper and has been left for future work. 
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r \- X ■. pt{x, r) 



(VAR) 



r \- Cl : (ki. n, A) r,o : dose{Ki. n, T) h 62 : (k2- T2, A) 

n- let o = ei in 62 : T A) 



S /0 (LET) 



where S = saf («i U K2, A), = nS|t«(«iUK2)-tf(r’) 

r = S^T2, -T' = a U a, k- = unresolved {Sa{k,i U K2), F') 



r,u : t' e : {k. t, F') 

F h Xu. e : (k. t' ^ r, F') 



(ABS) 



r h ei : {ki. Ti, A) r h 62 : {K.2.T2, A) 

rhei 62 : («lt*„(,,r)-T A) 



S' = Unify{{Ti = t 2 ^ a},ft(r)) 
S yf 0 nof ambiguous{tv{S aS K i) , 
K,tv{T,F)) 

(APPL) 



where S = saf (S(ki U K2), A), S21 = r|S|t«(S(«;iUK2))-t«(A’ a is a fresh 

type variable 

r = SaSo, F' = Fi U F2, K = unresolved {SaS{ki U K2),F') 



Figure 2: Type Rules of System CT 



For simplicity, in examples where it is not necessary, renaming of let-bound 
variables in constraints is not used. pt{x, F) is given as follows: 



pt{x, F) = 

if F{x) = 0 then fail else 
if F{x) = {yaj. K. t} then (k. t, F) 

else {{x' : r}. r, F[x' /x\), where F{x) = \y{aj)i. Ki. n > 1 , 

x' is a fresh term variable and r = lcg{{Ti\) 

lcg{{Ti}) gives the least common generalisation of {xi}. It takes into account 
the fact that, for example, A(;({lnt — > Int,Bool — > Bool}) is a ^ a, for some 
a, and not a —>■ a' , for some other type variable a' ^ a. Other simple examples: 
lcg{{Tree Int,List Int}) = a Int and lcg{{Tree / 3 , List / 3 }) = a a' . Due to 
reasons of space, we do not present the definition of leg. 

Rule (LET) uses function close, to quantify types over type variables that are 
not free in a typing context: close^A, F) = Va^ . a, where {aj} = A(a) — tv{F). 

Rule (APPL) has a premise with a type that is not in a functional form, and 
uses a fresh type variable, instead of having the usual premise with a functional 
type. This occurs because of overloading, as illustrated by the following simple 
example. Let F = {x \ Int,a; : Int — > Int, 1 : Int}. In this context the type 
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derived for x is not a functional type; we derive instead F \- x \ {x \ a\ . a. Then 
r \- xl Int is derivable, only with rule (APPL) as presented. 

Overloading resolution in rule (APPL) is based on two tests. Consider an 
application e e' . The first test guarantees that all constraints occurring in types 
of both e and e' , after unification, are a i ah e. This is based on function sat, 
also used in rule (LET) to control overloading resolution. 

sat {k, F) returns a set of substitutions that unifies types of overloaded sym- 
bols in K, with the corresponding types for these symbols in F. It is defined 
inductively as follows, where we assume that quantified type variables (of types 
in F) are distinct from those in tv{K,F): 



sat (0, F) = {id} 

sat {{o : t},F) = UcTierio) {-S' I S = Unify{{T = nj, V) and sat{SKi,SF) yf 0} 

where V = tv{Ti) — ({(oj)^} U tv{r)) and at = V(o;j)i. Ki. ti 
S at{{0 : t} U K, T) = Ussesot ({o:r},r) Osij&sat (SiK,,Sir){^V ° 

To elucidate the meaning of sat, let T = {f : Int — ^ Float,! : Float 
Int, one : Int, one : Float}. Then sat {{f : a —>■ /3, one : a},/^) is a set with 
two substitutions, say {S'i,S' 2 |, where 5'i(o;) = Int and 5'i(/3) = Float), and 
£' 2 ( 0 ;) = Float and S2{f3) = Int). 

After the first test, any free type variable in constraints of types of e or e' that 
is mapped (by substitutions given by sat) to a single type a, is replaced by a, 
by application of . Applying thus eliminates constraints when overloading 
has been resolved. 

Function unresolved is used to include unresolved constraints, if type a above 
is itself the type of an overloaded symbol. For example, if member is overloaded 
for testing membership in lists and trees, having type {member : a f3 a 
Bool}, a P a Bool in a context with typings member : Va p. {= : a a 
Bool}, a ^ [a] ^ Bool and member : Va p. {= : a ^ a ^ Bool}, a — > Tree a — > 
Bool, then, in a context as above that has also typings I : [a'], x : a' , member x I 
has type {= : a' ^ a' ^ Bool}. Bool. Function unresolved is defined as follows: 



unresolved (0, T) = 0 

unresolved ({0 : t} U k, F) = k' U unresolved{n, F) 
where n' = if sat{{o : r}, F) = {S'}, for some S, 

then unresolved{Sn' ,F), where Va^. k' .t' G F{o), St = St' 
else {o : t} 



The second test detects ambiguity by looking at the resulting constraint 
set K. This includes all constraints for both e and e' , after unification and (pos- 
sibly) constraint elimination. Predicate ambiguous issues an error if and only if 
overloading can no longer be resolved. It is defined as follows: 
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ambiguous{Vi, K, V) = V ^ % and V C Vi 
where V = Iv^k) — tv{K\y) 



Type variables in a constraint of a constrained type k. t either occur free in r 
or in the relevant typing context, or occur in another constraint with this prop- 
erty. Consider, for example. If h f one : {f : a — *■ /3, one : a}. /3 (cf. section 2). 
Type variable a does not occur in tv{T,r) = {/3}, but constraint {one : a} is 
captured by operation (where k = |f : a — > /3, one : a}). In general, a 

type variable may occur in tv{K) — tv{K IL(T,r)) if and only if the type variable 
does not appear in a constraint of the type of the function being applied (i.e. it 
does not appear in S'^S'ki). It may appear though in a constraint of the argu- 
ment’s type. For example. To h fst (True, one) : Bool, where k = {one : /3} 
and = 0 and ambiguous{%, {one : /?}, 0) is false. 

Example Tg 1/ g one : {g : a — > Int, one : a}. Int (see section 2) illustrates 
detection of a type error by predicate ambiguous. We have that k = {g : a ^ 
Int, one : a} yf /tjg. There is a constraint in the type of the applied function 
which should have been resolved (it would never be resolved in a later context) . 

4 Type Inference 

Figure 3 presents the type inference algorithm, PPc, which gives principal pairs 
(type and context) for a given term. It allows local overloading only of symbols 
with closed types. ^ It is proved sound with respect to the version of the type 
system that uses this overloading policy (i.e. pc below, instead of p), and to 
compute principal typings. The overloading policy is given by: 

Pc{o : Vaj. K. T, T) = (T = 0) or 

tv{\/aj. k.t) = % and for each a = y{/3k). k' . P G T 
unify{{T = r'}) fails and tv{a) = 0 

Pc requires closed types only for overloaded symbols (T = 0 means no typings 
for o in the relevant typing context, and in this case . k. t may have free type 
variables). Any core-ML expression is a well- formed expression in System CT. 

For simplicity, a-conversions are not considered, following the assumption 
that if a variable is let-bound, then it is not lambda-bound. 

PPc uses i g e i e A, which are sets of elements x : (ct, T). Pair 
(cr, T) is called an entry for x in A. We write A{x) for the set of entries of x in 
A, and A* (a:) for the set of first elements (types) in these entries. 

Fresh type variables are assumed to be chosen so as to be different from 
any other type variable, including any type variable that occurs free in a typing 
context (in the type system, this assumption is not necessary). 

Provably sound and complete type inference for local overloading of symbols with 
non-closed types is, as far as we know, an open problem. 
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pte{x,A) gives both type and context for x in A, as pt{x,r), but requiring 
fresh type variables to be introduced for let-bound variables, as defined below: 



pte{x, A) = 

if A{x) = 0 then (a, {x : a}), where a is a fresh type variable else 
if A{x) = {(Voj . K. T, -T)} then (k. t, F), 

with quantified type variables {aj} renamed as fresh type variables 
else {{x' : lcg{{Ti})}.lcg{{Ti}),[jri[x' /x\), 
where A{x) = {(V(o;j)i. Ki. r*, Fi)} and x' is a fresh term variable 



PPc{x, A) = pte{x, A) 

PPc{\u.e, A) = 

let (k. r, P) = PPc{e, A) 

in if u : t' G P, for some r' then (k. t' ^ t, P — {u : r'}) 
else (k. a ^ t, P), where a is a fresh type variable 
PPc{ei 62, A) = 

let (ki. ti,A) = PPc{ei,A), (k2- t2,P2) = PPc{e2,A) 

S = unify{{Tu = \ u : Tu G Pi and u : ri £ A} U {ri = T2 ^ a}) 

where a is a fresh type variable 
r = SPi LISP2, S = sat{S Ki U Sk2,P') 

in if S = 0 then fail 

else let Sa = p|S, P — SaP', t = SaSu, 

V = tv{r, r), K = unresolved{S aS{ki U K2),P) 
in if ambiguous{tv{S aS Ki) , k, V) then fail else (K|y. r, F) 
PPc{let o = ei in 62 ,^) = 

let (ki. Ti,Pi) = PPc{ei,A), a = close{ni. n,A) 
in if pc{o, A^{oyj does not hold then fail 

else let A = Au {o : {a, A)}, {n2. T2, P2) = PPc{e2, A) 

S = unify{{Tu = r ' | rt : r„ G A, u : A G r2}) 

A = SPi USA, S = sat{S Ki U Sk2,P') 
in if S = 0 then fail 

else let S21 = flS. -^ = SaP', t = SaSt2 

V = tv{r, P), K = unresolved{SAS{Ki U K-2), P) 
in {k\v- t,P) 



Figure 3: Type inference for System CT 



PPc substitutes type variables that occur free in a typing context, reflect- 
ing the contexts in which corresponding free term variables are used, sate used 
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in PPc is simplified (with repect to its counterpart sat) due to allowing local 
overloading only of symbols with closed types: 



sate (0) r) = {id} 

sate ({o : t},P) = Uaier(o){'5' I ^ = unify{{T = rj) and sat{SKi,P) ^ 0} 
where Ui = V(o;j)i. Ki. Ti 

sate ({o : t} LI K, P) = Usiesat ({o:r},r) UsySsot ° 

4.1 Soundness and Completeness 

In this section we prove soundness and completeness of PPc with respect to the 
version of System CT that uses the overloading policy given by pc- 

Definition 1 A typing context P is aid ii i) u ■. a & P implies that ct is a 
simple type, ii) ui : ai G P, U2 '■ 02 G P, ci ^02, implies that ui ^ U2, and iii) 
o : a G P implies that p{a, P{o) — {cr}) holds. 



Definition 2 An -c ed typing context is a valid typing context with the 
property that o \ a\,o \ U2 G P , a\ ^ 02 implies that tv{a\, (T 2 ) = 0- 



Definition 3 A typing environment A is aid if, for all x : {Vaj.K.T, P) e A, 
P is o-closed, p| sat{n, P) = id and unresolved{n, P) = k. 

Definition 4 P' extends (or is an extension of) P if whenever X is the set of 
all typings for x in P, then X is also the set of all typings for x va P' . 

Definition 5 Ar stands for {o : (a,P) \ o : a G P,o G O}, Ur stands for {u : 
T \ u : T G P, u G hi} and Oa = {o : cr \ o G O and o : {a, P) G A for some P}. 



Definition 6 k.t ^5 k' . t' if S{k. t) = k' . t' , and P :<s P' if P' extends SP. 

Lemma 1 If A h e : (cr, Pq) is provable and P U P' is an extension of P, then 
P LI P' \- e : (cr, Pq) is provable, where Pq is an extension of /q. 

Lemma 2 If PPc{e,A) = {k. t,P), where A is valid, then P is valid, tv{P) = 
tv{close{K. r, P)), P| sat{n, P) = id and unresolved{n, P) = k. 

Lemma 3 (Substitution Lemma) If P G e : {k. t,P') is provable, where 
P is -c ed, and S, are such that dom{S) C tv{P), satciSn, SP') yf 0 
and = f]sat{SK, SP'), then S^SP hg e : (k'. t',S^SP') is provable, where 
k'.t' = S^\tv(r)S{K.T) or k' .t' = {S^Sk,)\y-S^St, where V = tv{S^Sr, S^SP). 
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Theorem 1 (Soundness of PPc) If PPc{e,A) = {k. t,P), where A is valid, 
then Oa U Ur e ■ {k- t, P') is provable, where P' = Oa U P. 



Theorem 2 (Completeness) Let Pq be -c ed. If Iq h e : (kq- to,P') is 
provable then either: i) PPc{e,Aro) = {k. t,P) and there is S such that Oa U 
Ur As ro and k.t As kq.tq, or ii) PPc{e, Ar„) fails and e has a subexpression 
of the form let o = ei in C2 such that P\\- e\ ■. {ki. Ti,-r() is provable in the 
derivation of Iq h e : (ko-tq, P'), for some A, r{, ki.ti, but Pi\~ a : (k^.t^, _Tf) 
is also provable, for some T", k). such that k). ^5^ ki- ti, for some Si, and 

Pc{dose{K[. t[, Pi) , Pi{o)) does not hold. 

An example of item (b) is let / = Xx. x in let / = Xy. y in . . . . Types 
Int ^ Int and Float — > Float can be derived for Xx. x and Xy. y, respectively, 
and overloading of f with these two definitions is allowed. PPc, however, infers 
the most general type for each of these expressions, namely Va.a ^ a, and thus 
does not allow overloading with these two definitions. 



Principal Typings 

Definition 7 A i g be is a pair (e,/o)) where e is an expression and 
Pq is a valid typing context. A i g i for this typing problem is a pair 
{k. t,P) such that P As Po, for some S, and Che: (k. t,P') is provable, for 
some P'. It is the ge e a if, for every other typing solution {s'. t',P') to 
this problem, there exists S such that P As A' and k. t As . t' . 



Theorem 3 (Principal Typings) If PPc{e,Arg) = {k. t,P), where Pq is - 
c ed, then (k. t,Oa d Ur) is the most general solution for (e,/o), and if 
PPc{e, Arg) fails, then (e,/o) does not have a most general solution. 

5 Conclusion and Further Work 

The type inference algorithm presented in this paper computes most general 
typings and supports overloading and polymorphism without the need for dec- 
larations or annotations, and with the only restriction that types of local over- 
loaded definitions must be closed types. No language construct is introduced 
for the purpose of coping with overloading. The context-dependent overloading 
policy, controlled by a single predicate used in let bindings, allows overloading of 
constants and other similar forms of overloadings. Information provided by the 
context in which an expression appears is used to detect ambiguity on the use 
of overloaded symbols. When there is ambiguity, a type error is detected, and 
when it is possible for overloading to be resolved further on in a later context, 
this is reflected in the type of the expression. 

Our work is a continuation of previous works directed towards a comprehen- 
sive support for overloading, together with polymorphism and type inference. 
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The mechanism of type classes used in Haskell represented a big step forward 
in this direction. In an upcoming article, a formal semantics of the language of 
System CT will be presented, together with a type soundness theorem. Further 
work involves incorporating the type inference algorithm in a modern functional 
language, and studying support for subtyping and separate compilation. We have 
a prototype implementation, and are developping it with the aim of exploring 
further the idea of using overloading to support writing reusable code. 

Though we have not discussed the efficiency and time complexity of the 
type inference algorithm in this article, upon a preliminary evaluation we think 
that its efficiency should be approximately the same as that of the algorithm 
used for example for ML. We do not have yet a result on the complexity of 
the type inference algorithm but we plan to study the subject in detail and 
perform extensive experimentations with our prototype. We note that the cost 
of computing sat, as given in this paper, is proportional to m and n, where m is 
the number of typings on a given constraint set and n is the (average) number 
of overloadings of a given symbol. Usually, both m and n are small. Moreover, 
for any given typing o : r occurring in a given constraint set k, the number of 
substitutions obtained as a result of unifying r with typings for o in a given 
typing context is “even smaller” . If this number is zero, this can eliminate the 
need to compute all other unifications for the remaining constraints in k. Other 
optimizations may be worthwhile. We expect a practical implementation of our 
type inference algorithm in a language such as Haskell or SML to be efficient. 
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Abstract. We prove the correctness of a multi-level partial evaluator 
and of an information flow analysis for Abadi and Cardelli’s FObi<-, 
a simply typed object calculus with function and object types, object 
subtyping and subsumption. 



1 Introduction 

Ob ec ca c i, in particular the c-calculi of Abadi and Cardelli [3] , were intro- 
duced to provide a foundational paradigm for object-oriented languages in the 
same way A-calculi provide a foundational paradigm for functional languages. 
The work of Abadi and Cardelli was followed by a number of attempts to scale 
up results from A-calculi to c-calculi, including compilation [12], control flow 
analysis [22] and operational semantics [13]. 

Pa m e a a i [16] is an optimization technique which exploits partial 
information about a program’s input to generate a specialized program with 
a locally similar behavior. More precisely, a partial evaluator takes as input a 
program p(xi, . . . , Xn+m) and some fixed partial input for p, say X\, . . . ,Xn, and 
returns a specialized program such that for all inputs cc„+i, . . . , Xn+m'- 

P{xi,...,Xn) (^n+1 ; • ■ • : Xn-\-m) ~ ; ■ • ■ ; ^n+m) 

The specialized program is produced in two phases: ^ first one defines a bi di g- 
t e a a i (BTA) which annotates program points as a ic or known and 
d a ic ov unknown. Then the annotated program is fed to a ecia i e which 
evaluates programs according to the directives provided by the annotations — 
only known expressions are reduced. A non-standard type system for annotated 
expressions is used to enforce that all known subexpressions have been eliminated 
from the specialized program. 

If a i a a i (IFA) is an analysis to establish the absence of 

information leakage in programs. IFA proceeds by annotating program points as 
b ic or ec e . A non-standard type system for annotated expressions is used 
to enforce a -i e fe e ce property: secret data cannot be revealed in the 
public output of a legal program. In other words, a legal program with secret 

^ We consider offline partial evaluation only. 
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input and public output must be constant — provided the output is of some base 
type. 

Both BTA and IFA may be generalized to allow for an arbitrary set of 
binding-times or security levels, possibly with some extra structure, e.g. that 
of a partial order or of a semi-lattice. This further generality allows to capture a 
number of situations not allowed by standard BTA and IFA. In particular, i- 

e e BTA, i.e. BTA over an arbitrary set of binding-times, allows to distinguish 
between run-time, link-time and compile-time [20], or to stage computations in 
successive steps [11]. 

It is folklore that BTA and IFA are closely related [2,23,28]. In particular, 
both may be formalized as a non-standard type system and similar proof tech- 
niques may be used to establish the correctness of both analyses. In this paper, 
we detail the similarities (and differences) between BTA and IFA in the context 
of FObi<:, a first-order typed (^-calculus with object subtyping and subsumption 
[3, Chapter 8]. In Section 3, we define two non-standard type systems for IFA 
and BTA. In Section 4, we prove the correctness of both analyses: 

1. BTA: this involves defining for each binding-time 4> a specializer which elim- 
inates all subexpressions known at (j) and proving (1) a subject reduction 
theorem for the specializers (2) a progress theorem stating that a specializer 
never gets stuck, i.e. only terminates when all subexpressions known at (j) 
have been eliminated (3) a soundness theorem that specializers preserve the 
semantics of programs; 

2. IFA: this involves defining an operational semantics for the annotated calcu- 
lus and proving (1) a subject reduction theorem for the operational semantics 
(2) a non-interference theorem stating that a legal program whose output 
is of base type and has a level of security (j) must be constant w.r.t. inputs 
whose level of security is not inferior or equal to 4>. 

Our proof of correctness of IFA is purely syntactic, as in e.g. [15,26]. Indeed, 
semantical proofs as in e.g. [2] would require a fair amount of domain-theoretic 
background (see e.g. [3, Chapter 14]) and models only provide a limited guidance 
as to the choice of typing rules for the annotated calculi. 

Related work 

1. [11,14,21] study i- e e a la e a a i , but none of these works focuses 
on the question of correctness. In [28], Thiemann and Klaeren prove the 
correctness of a multi-level partial evaluator for a first-order language but 
make the strong assumption that the binding-times form a linear order; 

2. a la e a a i f b ec - le ed a g age is studied in [7,17,25] while 

Bertino e . a . [5] study if at f b ec - le ed e . Build- 

ing on [19], Myers [18] formalizes information flow for Java (JFlow). However, 
none of those works address the issue of correctness; 

3. j/ at a a i , which initiates from early work by Bell and La- 

Padula [4] and by the Dennings [9,10], has since been the subject of much 
attention, see e.g. [1,2,15,26] for type-based approaches. While these works 
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have been shown able to handle features such as side-effects and multi- 
threading, they do not treat objects. 

Conventions and notations Throughout the paper, we assume given a fixed 
set V of a lah e and a fixed set C of ahe ; we let x, x' ,y, z . . . and I, V , U . . . 
range over V and £ respectively. Moreover we assume given a semi-lattice {D, C, 
-b) of levels — i.e. {T>, C) is a partial order and -b is a binary join operation on 

2 Annotated FOb^^. 

Binding-time and information flow analyses are performed via non-standard type 
systems. While both systems arise as annotated variants of FObi<- and share 
the same set of types and expressions, the type system hi/ for information flow 
is more liberal than the type system \~bt for binding-time analysis. As discussed 
below, these differences are justified by the respective aims of the systems. In a 
first stage, we introduce hi/ and then derive \~bt by imposing suitable restrictions 
on hi/. 



2.1 Information Flow Analysis 



Our calculi are annotated variants of the calculus of [3, Chapter 8]. At a syntactic 
level, the only minor difference is that our calculi contain a base type nat of 
natural numbers as well as (annotated) numerals — the presence of a non-trivial 
base type simplifies the statements of our results. 



Definition 1 (Types, subtyping). 



1. The e U f (annotated) types i gi e h he ah ac a 



A,B 



(top type) 

nat"^ (natural numbers) 

A — B (function type) 

[k : Ai !<*<"]<#• (object type) 



he e 4> a ge e T>. B c e i , e e i e ha a he ahe i a 

h ec e a e at i e di i c . 

2. T/ie top-level annotation fa a a ed e A i de ed h top(A). Gi e 

a e A a d 4> gV, e e he he e h at ed h e act g he e - 

a at fAh top(A) -b <^. define 

3. S h t g < U t de ed h he e f Fig e 1. 



The annotated expressions match the standard expressions, to the exception of 
the lift operators which apply to elements of arbitrary type and allow to raise 
the level of an expression. 
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A < A 



A<B B<C 
A<C 



nat"^ < nat”^' 



top(A) c 4> 
A < T'^’ 



A' < A B<B' 0 C 0' 

A^‘^ B <A' B' [li : Ai < [i- ■ Ai 



Fig. 1. Subtyping 



Definition 2 (Annotated expressions, reduction). 

1. The e W f (annotated) expressions i de ed b he ab ac a 

w, w' ::= X (a tab e) 

\ n'^ ( e a ) 

I w@^w' (a ica i ) 

I X^x : A.w (ab ac i ) 

I [k = ^x, : A.w^ (bee) 

I w.’^l ( e h d i ca i ) 

I w.'^l A= <;x : A.w' ( e h d da e) 

I w+^ (if) 

Be ei,eeie ha a he abe i a b ec a e ai i e di i c . 

Substitution i de ed i he a a a d e{x := e'} de e he e f 

b i i g e' f a cc e ce f x. 

2. The e a i ^ifo i de ed b he e f Fig e 2, he e A = [h : 

Bi !<*<"]’/’ g (f not a e he c a ib e c e f he e e . If w -^if^ 

w' , e a w i a redex a d w' i i reduct. 

3. A e e i w reduces to w' , i e w ^if w' , if w' i b ai ed f w 

be ac i g he ef e ede fw. 

Note that z/-reduction does not discriminate on security annotations and is 
sound w.r.t. the operational theory of FObi<-; in other words, wi -^if W 2 implies 
|ici| — >oc I 1 C 2 I where |rci| is obtained from Wi by removing all annotations and 
— >oc is the reduction relation of FObi<-. 

Definition 3 (Typing). 

1. A context i a e e ce f dec a ai x\ \ Ai, ... ,Xn '■ An he e 

Xi, ... ,Xn G V a e ai i e di i a d A\, ... , A„ G U . We i e 

top(xi : Ai, . . . ,Xn ■ An) ^ (f if top(Ai) % 4> f e e 1 < i < n. We e 

F, F' , ... a ge e c e 

2. A judgment i a a e e f he f F \-^f w : A he e F i a c e , 
w GW a d A £U. 

3. The i g eai \~if i gi e b he e f Fig e 3. 
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X : B.w)@'^'w' —>ifg w{x ;= w'} 

[li = <;xi : A.Wi njj{xj ~ [k = <;Xi : A.Wi 

[h = <;Xi : A.Wi <= <;x : B.w' ^ifg [k = <;Xi : A.Wi ]^j-",lj=<;x : A.w'Y 

W+'f’ ^ifg W 



Fig. 2. Rules for z/-reduction 



~if n '^ ■. nat'^ 
-if X-. A 



if (a: ; A) e r 



r,x : A \~if w : B 
r \-if X^x ■.A.w.A^'^B 

r \~if Wo : A — B r \~if wi : A 
r hi/ : 5+^+^^ 

n A L. D if ^ = [Zi : Si 

^ and A' = [h : B, 

r hi/ [Zi = cxi : A.Wi : A' and C </- 

r hi/ w: [Zi ^Bi 

r hi/ w.’^Zi : B+^+^^ 

Bh/ w:A B,a::AK/ wAB. ^ ^ ^ 

r hi/ w.’^Zi ^ ca: : A.w' : A+^^ 

r \~if w : A 

r hi/ w+’^ : A+’'’ 

HA<B 

r hi/ w : B 



if A < B 



Fig. 3. Typing rules for IFA 
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The type system is meant to enforce that expressions with a low-level of 
security (typically public data) do not depend on expressions with a high-level 
of security (typically secret data). This is achieved by ensuring that the top- 
level annotation of an expression is always inferior or equal than the top-level 
annotation of any of its types. Note that the rule for objects does not require that 
the type of self matches the type of an object: instead, we allow the type of self 
to be A = [li : Bi and the type of the object to be A' = [U : Bi 

with Ip 'Q tj)- This, together with the slightly unusual reduction rule for object 
selection, is crucial for subject reduction to hold. 

Re a 

1. \~if is sound w.r.t. h; in other words, T \~if w : A implies iTj h |A| : |r<;| 
where iTj, |A| are obtained from B,A by removing all annotations. 

2. Using the techniques of [-3], one can establish the soundness and complete- 
ness of algorithmic typing — defined in the obvious way. It follows that it is 
decidable whether any given B \~if w : A is derivable, provided U and -I- 
are decidable. 




2.2 Binding-Time Analysis 

The BTA is obtained from that of IFA by imposing suitable restrictions on the 
typing rules. First, only types whose top-level annotation is smaller than the 
top-level annotation of its subexpressions are considered, see e.g. [27]. 

Definition 4. The e f BT types i de ed b he e f Fig e 4 - 

We now turn to the operational semantics. Unlike the system for information 
flow, we consider a family of reduction strategies for every (p G V. Informally, 
— will contract the leftmost outermost redex whose topmost annotation is 
smaller or equal to <p. 

Definition 5 (Operational semantics, residual expressions). 

1. The e a i ~^to i de ed h he e f Fig e 5, he e i i a ed 

ip \Z (p a d A = [li \ Bi !<»<"]’/' g d not a e he c a ib e c e f 
he e e . If w w' , e a w i a <()-redex a d w' i i reduct. 
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w{x := 

[h = <;xi : A.Wi Wi{xi := [U = CXi : A.Wi i<i<"]V''} 

\U = CXi : A.Wi ^ Cx : B.w' ->t \U = cXi : A.wt ,h = cx : 

(A’^x : B.w)+’^' A’^+’^'x : B.w 

{[li = cXi : B.Wi i<i<"]V')+’^' = ^xi : B.Wi 1<'<"]V-+V-' 

Fig. 5. Specialization rules 

a 1 e e i w ^-specializes to w' , i e w w' , if w' i b ai ed f 
w b c ac i g he ef e 4>- ede f w. 

3. A e e i w i </)-residual, i e w G TZ^, if a i a a i (e ce 

he if a a i )ae%ipadide c ai a be e i f 
he f u+’^ he e V gY i.e. v i a e a , a ab ac i a b ec . 

Equivalently, (/(-residual terms are those which cannot be specialized at a level 
lower than (/>. 

Lemma 1. If w G TZ‘^ a d if Q <j), he he e i w' GW eh ha w w' . 
P f. By induction on the structure of the expressions. 



r l~bt Wo : A B r \~bt wi : A 
P hbt wo@'^wi : B 

r Gu w. [li = Bi 
r Gm w.Yi : Bi 

r Gbt w : A r,x : A Gbt w' : Bi 
r Gbt w.'^li <i= ?x : Al.ui' : A 

r Gbt w : A 
r Gbt : B 

Fig. 6. Typing rules for BTA 



We finally turn to the typing system. Its aim is to enforce that a closed expression 
w whose type A satisfies top(A) ^ (/> may be (/(-specialized to a (/(-residual term, 
unless (/(-specialization on w does not terminate. This is achieved by imposing 
suitable restrictions to the rules of Gif. 



if A = [li : Bi !<*<’"]</> 
if A < B 
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1. the subsumption rule (sub) is modified^ so that expressions have a unique 
binding-time, see Subsection 2.3; 

2. the (app), (sel) and (upd) rules are restricted so as to avoid stuck redexes 
such as {X^x : A.w)@'^w' with ip ^ (j). 

Definition 6. The i g e a i \~bt i de ed h he e f Fig e 6. 

Note that — is sound w.r.t. the operational theory of FObi<- and \~bt is sound 

w.r.t. h. 

2.3 Design Choices 

In designing an annotated type system for FOhi<c-., we are led to several design 
choices. The first choice has to do with the treatment of subtyping, as discussed 
in [27]: 

1. one can adopt the subsumption rule (sub) as in This is the i c i - 
ba ed a ach; 

2. one can adopt a restricted subsumption rule as in \~bt so that all the types of 
an expression have the same top-level. This is the e a i a -ba ed a ach. 

Note this choice has some impact on the operational semantics of the system, as 
rules such as would not be sound for hbt- 

The second choice has to do with lifting. Lifting is often restricted to base 
types yet better residual programs may be obtained by allowing more general 
forms of lifting. Here we allow lifting on arbitrary types. The specialization rules 
for lifting are however rather mild: following e.g. [27], one could envision more 
aggressive specialization rules which propagate lift annotations. However, the 
standard rule for lifted products is based on surjective pairing (SP)^ and, as 
pointed out in [3, Section 7.6.2], SP is not sound for objects. While we have not 
checked the details, it may be possible to encounter specialization rules which 
propagate lift annotations and which do not rely on SP. 

The third choice has to do with typing rules for destructors. While we have 
not checked the details, one could envision more liberal typing rules such as 

F \~bt wq : A B F w\ '■ A ^ / 

F hbt : B+^ 

However this would require modifying the operational semantics so that redexes 
of the form {X^x : A.w)@'^w' with 4> Q ip may be specialized at level <p and so 
that subject reduction holds. For example, one would need to adopt the rule 

{X'I’x : A.w)@'>’'w' (rc{:r := („;')+t°p(^)})+V'' 

for ip Q ip' ■ The notion of residual expression would also need to be modified so 
as for correctness results to hold. 

^ For the sake of conciseness, we consider a single rule which may introduce unneces- 
sary lifts, namely when top(H) = top(B). This may be easily fixed by maintaining the 
lift rule and restricting subsumption to types having the same top-level annotation. 
^ SP states that two objects o and o' are equal (w.r.t. the equational theory of FObi<-,) 
at type \h : Bi iff for 1 < i < n, o.U is equal to o' .h at type Bi. 
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3 Correctness of the Analyses 

In this section, we establish the correctness of IFA by proving a non-interference 
theorem and of BTA by proving the soundness of partial evaluation. 

3.1 Correctness of IFA Analysis 

First, one needs to show that ^/-reduction preserves typing. 

Lemma 2 (Subject Reduction). If F \~if w : A a d w ^if w' he F \- if 
w' : A. 

P f. By induction on the structure of the derivation of F \~if w : A. 

Second, we need to analyze the possible shapes of legal terms and their behavior. 
To this end, we begin by classifying expressions into values, reducible expres- 
sions and irreducible expressions. Values are A-abstractions, numerals or objects. 
Irreducible elements are those whose “heart” is a variable whereas reducible ex- 
pressions are those whose “heart” is a value. The notion of “heart” can be made 
precise using the notion of experiment, see e.g. [13]; however we prefer to give 
an inductive definition of the classes involved. 

Definition 7. The e V / values, I / irreducible expressions a d R / re- 
ducible expressions a e de ed b he ab ac a 

a G V = A^x : A.w I I [k = <;Xi : A.Wi 

c S I = X I c@^w I cAl I cAl <;= cx : A.w \ 

s e R = a@‘>’w I s@'^w I aAl \ sAl \ aAl <= <;x : A.w \ s.'^l <= ^x : A.w \ a+'^ \ s+'^ 
he e e, ei, . . . , e„ € W. 

One easily checks that W = V U I U R. 

Lemma 3. If F \~if w : A a d w G M. he w -^tf w' f e w' G W. 

P f. By induction on w G R. 

Lemma 4. If F,x : C hi/ w : A, F hi/ v: C,wGM.adw -^if w' he 
w{x := x} ^i/ w'{x := u}. 

P f. By induction on w G R. 

Lemma 5. If F hi/ w \ A, top(F) ^ (f a d w G I, he top(A) ^ (j). 

P f. By induction on the derivation of F hi/ w : A. We treat the case of 
application so assume w = Wq@'^wi and the last rule is 

F hi/ wq : A — F hi/ w± : A 
F hi/ wo@^wi : F+h+h' 

Necessarily wq G I so by induction hypothesis ip' % p. Now ip' C top(F+h+h j 
hence top(F+h+h ) cp. 
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Lemma 6. If F \~if w : A i h top(L) top(A) he w & Y w —>if w' . 

P f. By Lemma 5, w ^ I hence re G V or re G R. In the latter case, w ^if w' 

by Lemma 3. 

Proposition 1. If F \~if w \ A i h top(P) ^ top(A) he w -^if w' gY w 
di e ge , i.e. w -^if wi -^if W 2 ~^if i h Wi G M. f e e i > 1. 

P f. By Lemma 6 and Subject Reduction. 

The above results can now be used to establish non-interference. 

Proposition 2 (Non-interference). A e ha F,x : A Gif w : nat^ , 
F Gif w' : A a d F Gif w" : A. Iftop{F,x : A) he f e e v gY, 

w{x := w'} ->*if V w{x := w”} -^if v 

P f. By Proposition 1, there are two possibilities: 

1. w Wq G Y then wq must be of the form n^. Hence w{x := w'} 
and w{x := w”} vA’ so we are done; 

2. w wi W 2 ... with Wi G R for every * > 1. By Lemma 4, 

w{x := w'} Wi{x := w'} W2{x := w'} . . . 
w{x := w”) wi{x := w"} W2{x := w”} . . . 

so we are done. 

3.2 Correctness of BTA 

Specialization preserves typing; thus we are able to specialize expressions that 
have been specialized previously. This is the key to staging specialization in 
successive steps, see e.g. [28]. 

Lemma 7 (Subject Reduction). If F hf,t w : A a d w w' he F Gtt 
w' : A. 

P f. By induction on the structure of the derivation of F G^ w : A. We treat 
somes cases: 

1. assume w = wo@'^wi with wq = \'^x : A' .W 2 , w' = W 2 {x := (wi)+*°p^"^'^} 
and the last rule is 

F Gm WQ-. A^^ B F Gm wi : A 
P : B 

Necessarily A< A! and there exists B' < B such that F,x : A' Gm W 2 '■ B' . 
By subsumption F ^ : A’ and by substitution 

F Gu W2{x := (wi)+*°P(^')| : B 
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2. assume w = wq. ^Ij with wo = [U = ^Xi : A.w^ w' = Wj{xj := Wq} 

and the last rule is 

r Ht tup : [k = 
r hbt : Bj 

Necessarily A=[li = Bi !<*<"]’/> with f/'' C ■)/) and B,Xi : A \-m Wi : Bi for 
1 < i < n. Set Wq = [U = : A.Wi . By object, B w'g : [k = 

Bi and by substitution B \~bt Wj{xj := Wq} : Bj. 

Lemma 8. If B \~i,t w : A, top(A) Q(j)adwG]S. he w w' . 

P f. By induction on the derivation of B \~bt w : A. We treat some cases: 

1. assume that w = Wo@'^Wi and the last rule is application 

B \-bt Wo : A B B '^bt wi ■. A 
B \~bt wo@’^wi : B 

with f) C top(i?) C (j). There are two cases to treat: 

(a) if Wq G V then necessarily wq is a A’^-abstraction, say Wq = X^x : A' .W 2 , 

and hence w = wq@'^wi w' = W 2 {x := ^}. 

(b) if wp G M then by induction hypothesis wo Wq and hence wo@’^wi 

w'o@'^wi. 

2. assume w = Wq^ and the last rule is lift 

B \~bt Wq : A 
B Ht w+^ : A+^ 

By hypothesis, top(yl+'^) C (p and hence top(A) C p. There are two cases to 
treat: 

(a) if wp G M then by induction hypothesis wq Wq and hence Wq^ 

(b) if wp G V then necessarily Wq^ w' . 

Lemma 9. If B \~bt w : A, top(T) % p a d w Gl, he top(A) % (p. 

P f. By induction on the derivation of B \~bt w : A. We treat some cases: 

1. if w G V and the last rule is start, then {w : A) G B and we have top(A) ^ p 
from the definition of top(T) ^ p. 

2. if w = wo@^w\ and the last rule is application 

B hbt Wp : A B B '^bt Wi ■. A 
B \~bt wq@’^wi : B 

Then wp G I so by induction hypothesis p % p. Now p C top(i?) by the 
definition of annotated types, hence top(i?) % p. 
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3. if w = w' .1 and the last rule is selection 

r Ht W : [k = B, 
r w'.^k : B, 

Then re' G I so by induction hypothesis V' 2 '/'• Now ip C top(i?i) by the 
definition of annotated types, hence top(i?i) % p. 

4. iiw = w'.^h 4= <;x : A.w\ and the last rule is update 



r w' ■. A r,x : A \~M wi : Bj 
r \~bt w'Ali 4 = <,x : A.wi : A 



with A =[h: B, 



Then re' G I so by induction hypothesis we got directly top(A) % </>. 

5. if w = Wq^ and the last rule is lift 



r \-bt wq : A 

r hbt : A+^ 

Necessarily wq G I. By induction hypothesis, top(A) ^ p. Now top(Gl) C 
top(B) and hence top(i?) % p. 

Later we will use the following reformulation of Lemma 9: if B \~bt w : A, 
top(T) % 4> and top(A) C </>, then w ^1. 

Lemma 10 (No stuck). If F hf,t w : B ih top(i?), top(T) % tp, he e f 
he e le be h d : 

1. w G TZ^, i.e. w i (p- e id a ; 

2. w w' f e w' €W. 

P f. By induction on the derivation of F ht,t w ■ A. We treat some cases: 

1. application: assume w = wq@’^wi and the last rule is 

F hbt Wq : A B F Wi ■. A 
F \~bt wo@^wi : B 

By construction, %p \— top(A), top(i?). By assumption, top(_B), top(_T) % p. 
There are two possibilities: 

(a) li Ip \F p: by Lemma 9 wq ^ I, so wq@^wi ^ I and hence wq@^wi G M. 
We conclude by Lemma 8; 

(b) ii p p-. then top(A), top(B) if- p. By induction hypothesis, either 

Wo Wq or Wo G TZ‘^ and either wi — w[ or wi G TZ^. There are 

three cases to treat: 

i. Wo G TZ'^ and wi G TZ^^: wo@"^wi G TZ*] 

ii. Wo G IZ‘^ and wi — w(: wo@’^w\ — wo@^w[; 

iii. Wo w'q: wq@^wi w'o@^wi. 
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2. abstraction: assume w = X^x : A.wo and the last rule is 

r,x : A \-bt wq : B 
r hbt : A.wo :A^^B 

By construction, ijj C top(A), top(i3). By assumption, ^,top(I^) % cf). Hence 
top(H),top(H) % (j) and by induction hypothesis, wq — w' or wo G TZ^. In 
the first case, w X^x : A.w' . In the second case, X'^x : A.wq G TZ'^. 

3. object: assume w = [k = <;Xi : A.Wi ^ith A = [k ■. Bi and 

the last rule is 

_E, Xi .A \~bt tUj . B^ 
r Ht [h = : A.w, : A 

By construction, ijj C top(Hi) for 1 < i < n. By assumption, top{r),ip % (f>. 
Hence top(Hi) % (j) and by induction hypothesis, Wi G TZ'^ or Wi w[ for 
1 < i < n. There are to cases to distinguish: 

(a) for all 1 < i < n we have Wi G TZ'^ then w G 72.'^; 

(b) for some 1 < * < n we have Wi w[ then [k = <;xi : A.Wi 

[k = <;xi : A.Wi , = <;Xj : A.w'^] where j is the smallest 

number such that Wj ^ TZ^. 

4. invocation: assume w = wq.'^U and the last rule is 

r WQ : [k = B, 

r \~bt Wo-'^h ■ Bi 

By construction, ijj C top(i?i). By assumption, top(T), top(-Bi) ^ (f>. There 
are two possibilities: 

(a) if ■!/; C by Lemma 9 wq ^ I, so wo-^k ^ I and hence wo-^h G K. By 
Lemma 8 Wq.'^U — s-f w' . 

(b) liip %(j): then by induction hypothesis, either wo — Wq or wg G TZ’^ . In 
the first case wg.'^li WQ.'^li whereas in the second case wg-'^h G TZ'^. 

5. lift: assume w = Wq'^ and the last rule is 

r \~bt Wg : A 

r hbt : A+^ 

By assumption top(H+’^) ^ (f). There are two cases to treat: 

(a) if top(H) C 0 then by Lemma 9, Wq'^ ^ I. Hence G M and by 
Lemma 8 Wq'^ w'; 

(b) if top(H) % (j): then by induction hypothesis, either wq w'g or wg G 
TZ'^. In the first case, Wq^ — w' . In the second case either wq G V in 
which case Wq'^ — w' or wg in which case Wq^ G TZ'^. 

In the sequel we let denotes the reflexive-transitive closure of — 

Proposition 3 (Correctness of binding-time analysis). If B \~bt w : A 
i h top{r),top{A) % (j) he e f he e le be h d: 

1. w^t w' a dw' & 7^'^; 

2. W Wi ^fw2^f... 

P f. Follows directly from no stuck and subject reduction. 
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4 Conclusions and Directions for Future Research 

We have defined and shown the correctness of IFA and BTA for FObi<-. In the 
future, it seems worth: 

1. extending our results to more powerful and realistic object calculi; 

2. scaling up to annotated type systems the existing translations from c-calculi 
to A- and 7r-calculi, see e.g. [6,24], in particular to reduce non-interference 
for the former to non-interference for the latter. 

Ac edge e We are grateful to F. van Raamsdonk and the anonymous 
referees for their constructive comments. Thanks to D. Teller and S. Villemot 
for implementing the annotated calculi. The first author is partially funded by 
the FCT grant PRAXIS/P/EEI/14172/1998. 
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Abstract This paper introduces a set of combinators for building lexi- 
cal analysers in a lazy functional language. During lexical analysis, the 
combinators generate a deterministic, table-driven analyser on the fly. 
Consequently, the presented method combines the efficiency of off-line 
scanner generators with the flexibility of the combinator approach. The 
method makes essential use of the lazy semantics of the implementation 
language Haskell. Finally, the paper discusses benchmarks of a scanner 
for the programming language C. 



1 Introduction 

There are two conceptually different approaches to obtaining a functional imple- 
mentation of a scanner or parser from a formal lexical or syntactic specification: 
(1) the specification is written in a special purpose language and translated into 
a functional program by a scanner or parser generator or (2) the specification is 
composed from a set of combinators provided by a scanner or parser combinator 
library. 

Both approaches have their advantages and were pursued in the past. There 
are a couple of generators (e.g., [8,2,5]) for widely used languages, such as Haskell 
and SML, as well as a number of combinator libraries (e.g., [3,4]). Usually, gener- 
ators produce more efficient scanners and parsers by implementing table-driven 
analysers [1], but this is, in the case of parsers, at the expense of expressiveness, 
as generators usually confine the specification to a restricted class of languages, 
such as, LALR(l). Furthermore, combinator libraries are easier to handle — no 
separate input language and generator program are necessary — and they can 
specify analysers for statically unknown grammars, i.e., the grammar can change 
during program execution. Recently, Swierstra and Duponcheel [7] introduced 
self-optimising parser combinators, which during parsing generate a determinis- 
tic analyser for LL(1) grammars, thus, combining the flexibility of combinators 
with the efficiency of generators. 

The present paper introduces a related technique for lexical analysers ( e e , 
for short). During application of the lexer, a deterministic, table-driven analyser 
is generated on the fly from a combinator-based lexical specification. Tokens are 
produced by user-defined ac i , the standard i ci e f he ge a ch is 
applied [1], and non-regular features, such as nested comments, are supported 
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by e a ac i . The described technique is fully implemented by a Haskell 
library, called Lexers, and the code is available for public used The efficiency 
of the technique was evaluated by benchmarking an implementation of a lexer 
for the programming language C. Despite the relation to the mentioned work 
of Swierstra and Duponcheel on parser generators, the presented technique is 
substantially different from theirs. 

An interesting aside is the use made of Haskell’s lazy evaluation semantics. 
The state transition tables generated by the lexer combinators to achieve de- 
terministic behaviour are represented by a cyclic tree structure, which requires 
either non-strict semantics or impure mutable structures. As an additional ad- 
vantage of laziness, only those fragments of the table are constructed that are 
actually needed to accept the input at hand. Thus, we avoid overly high startup 
costs for short inputs, which would be incurred in non-strict, but eager (= le- 
nient) languages like pH [6]. 

In summary, the central contributions are the following: 

— A new technique for on-line generation of state transition tables from regular 
expressions in a lazy functional language. 

— A combinator library for specifying lexical analysers, including often required 
non-regular features. 

— Experimental evaluation of the proposed table generation technique. 

The paper is structured as follows. Section 2 introduces the basic ideas of 
the combinator library and table generation. Section 3 defines the interface of 
the combinator library and Section 4 formalises the dynamic table generation. 
Section 5 presents benchmarks. Finally, Section 6 discusses related work and 
Section 7 concludes. 

2 Combinators and Automata 

Specifications of lexers essentially consist of pairs of a e e i and 
ac i , where the latter are program fragments that are executed as soon as 
the associated regular expression matches the current input. Actions usually 
generate tokens, which are consumed by a parser following the lexer. Regular 
expressions typically have the following structure [1] : 

— e matches the empty word. 

~ A single character c matches itself. 

~ r\ T 2 matches a word of which the first part is matched by ri and the second 
part by r 2 - 

— I t 2 matches a word that is either matched by r\ or by r 2 - 

— r* matches a word that consists of zero, one, or more successive words 
matched by r. 

— r+ matches a word that consists of one or more successive words matched 
by r. 

— rl matches a word that is either empty of matched by r. 

^ Download at http://www.score.is.tsukuba.ac.jp/~chak/ctk/ 
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Furthermore, we use [ci . . . c„] to abbreviate ci | • • • | Cn- For example, integer 
numbers are matched by -?[0 . . . 9]+, i.e., an optional minus sign is followed by 
a non-empty sequence of digits. The same regular expression can be expressed in 
Haskell as follows (we define the used combinators in detail in the next section) : 

(char 'quest' (alt [’O’ . . ’9’] ) ‘plus' epsilon 

or, in this paper with improved typesetting, as {char {alt [’O’..’9’])0 e. In a 
lexer specification, this regular expression would be paired with an action that, 
given the string — or, e e e — of a recognised integer, produces the correspond- 
ing token. 

A well known result from automata theory states that, for each regular ex- 
pression, there exists a i e a e a a (FA) that accepts exactly those 
words that are matched by the regular expression; more precisely, there even ex- 
ists a, de e i i ic i e a e a a (DFA), i.e., one where in each state, 
by looking at the next input symbol, we can decide deterministically into which 
state the automaton has to go next. This correspondence is exploited in scan- 
ner generators to produce a deterministic, table-driven analyser from a lexical 
specification. The technique presented here builds on the same theory. An ad- 
ditional complication, when handling a full lexical specification, as opposed to 
a single regular expression, is the requirement to match against a set of regular 
expressions in a single pass. 

By implementing matching of regular expression by a DFA, we get a ab e 
die e e . Such a lexer represents the a e a 1 1 g a h oi the automaton 
by a two-dimensional table. During lexical analysis, it traverses the transition 
graph by repeatedly indexing the table with the current automaton state and 
input symbol to obtain the next state. In the standard approach, the table is con- 
structed off-line by a scanner generator. More precisely, the regular expressions 
are either first transformed into a dee i i ic lea a (NFA), and 
then, the NFA is converted to an DFA or the DFA is directly obtained from the 
regular expressions; finally, the number of states of the DFA is minimised and 
often the table is stored in a compressed format, as it tends to be sparse. This 
standard technology is described in detail in compiler textbooks [9,1]. 

As we generate the automaton incrementally during lexing, we cannot use a 
multi-staged approach and we have to avoid expensive techniques, such as, the 
subset construction. We essentially build the state transition graph of a DFA 
directly from the regular expressions and we construct a node of the graph only 
if we actually reach it during lexing. Representing the graph directly, instead 
of encoding it in a table, facilitates incremental construction and reduces the 
storage requirements in comparison to an uncompressed table (the transition 
table is usually sparse). 



3 The Interface 

Before we discuss the details of automata construction, we have to fix the com- 
binator set used for the lexical specification. It consists of regular expressions. 
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actions, and meta actions, where regular expressions describe the structure of 
lexemes, actions specify the transformation of lexemes into tokens, and meta 
actions keep track of line numbers and implement non-regular features, such as, 
nested comments. 



3.1 Regular Expressions 

Sets of lexemes that should trigger the same action (i.e., which usually gener- 
ate the same sort of token) are specified by regular expressions that are freely 
constructed from a set of combinators, which resemble the operators on regular 
expressions discussed in the previous section. 

A regular expression is denoted by a Haskell expression of type {Rege ). 
Such a regular expression is, according to its type arguments, used in a lexer, 
which maintains an internal state of type and produces tokens of type — it 
would be possible to hide the type variables and add this point by using 
the non-standard feature of explicit universal quantification and at the cost 
of slightly complicating some other definitions. The following combinators^ are 
available for constructing regular expressions: 



e : 


: Rege 






— empty word 


cha : 


: Cha - 


-> Rege 




— single character 


(>) : 


: Rege 


Rege 


Rege 


— concatenation 




: Rege 


Rege 


— > Rege 


— alternatives 


(®) : 


: Rege 


Rege 


— > Rege 


— zero, one, or more rep. 


(®) : 


: Rege 


Rege 


— >■ Rege 


— one or more repetitions 


(?) : 


: Rege 


— > Rege 


Rege 


— zero or one occurences 



We can define (®), (0), and (?) in terms of the first four combinators; we shall 
return to the details of these definitions later. Furthermore, the following two 
definitions are useful for making regular expressions more concise: 



a :: [Cha ] Rege 

a [ci, . . . , c„] = cha ci • • • cj<i cha c„ 

i g :: S i g ^ Rege 

i g [ci, . . . , Cn] = cha ci > • • • > cha c„ 



Finally, the following precedence declarations apply: 



I 4 ®, 0 , ? 

i 3 > 

i 2 fcfa 

^ This presentation takes the freedom to improve on a purely ASCII-based typesetting 
of Haskell expressions. In ASCII, e is represented by epsilon, (>) by (+>), (t|<l) by 
(>l<), (®) by star, (®) by plus, and (?) by quest. 
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Given these combinators, it is straight forward to define familiar token types, 
e.g., identifiers: 

ide :: Rege 

ide = e e > ( e e idfCi digi )® e 

where 

e e = a ([’a’..’z’] [’A’..’Z’]) 

dzgz = a [’O’. .’9’] 

In other words, an identifier is composed out of a letter, followed by zero or more 
letters or digits. Note the use of e at the end of the regular expression; ® is an 
infix operator and requires a second argument. From the point of view of regular 
expressions, the more natural choice for ®, ®, and ? would be the use of (unary) 
postfix operators. However, Haskell does not have postfix operators and, even if 
it had, a unary operator would make the implementation more difficult; as we 
will see in Section 4, the binary nature of these operators allows an important 
optimization. 

3.2 Actions 

Whenever the lexer recognises a lexeme matching a given regular expression, it 
applies an action function to the lexeme and its position to produce a token. 

e Ac i =Sig^Pii — *■ Ma he 

An action may choose to produce no token (i.e., return N hi g); for example, 
if the lexeme represents white space or a comment. Using the function 

e ac i :: Rege ^ Ac i — > Le e 

we can bundle a regular expression with an action to form a lexer — the latter 
are denoted by types Le e with user-defined state and tokens . We can 
disjunctively combine a collection of such lexers with the following combinator: 

i 2 c|[a 

(c|[3) w Le e ^ Le e — >■ Le e 

Given these functions, let us continue the above example of lexing identifiers, 
i.e., the definition of the regular expression ide . If tokens are defined as 

da a T e = Lde T S i g P 1 1 



we can define a lexer that recognises identifiers only by 



e lde w Le e T e 

e lde = lde ^ e ac i ‘ (A 



,] {Lde T 



)) 
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A compound lexer that recognises sequences of identifiers separated by space 
characters can be defined as follows: 

e e :: Le e T e 
e e = e ide 

cjjci cha ’ ’ ‘ e ac i ‘ (A_ _ ^ A hi g) 



3.3 Meta Actions 

In addition to actions that produce tokens, we have meta actions, which alter 
the internal behaviour of the produced lexer. Like a normal action, a meta action 
is a function: 

e Me a = P 1 1 ^ {P i i , , Ma be {Le e )) 

Given the current position and a user-defined lexer state (of type ), a meta 
action produces an updated position and an updated user-defined state. Fur- 
thermore, it may choose to return a lexer that is used, instead of the current 
one, to analyse the next token. The user-defined state can, for example, be used 
to implement a ge routine or to maintain an identifier table during lexical 
analysis. In combination with the capability of returning a lexer, it can be used 
to implement non-regular features, such as, nested comments. We can realise the 
latter as follows: 

— The user-defined state keeps track of the current nesting level. 

— We use two different lexers: (a) the a da d e e recognises tokens outside 
of comments and (b) the c e e e keeps track of the nesting level while 
scanning though comments. 

— When the lexing process encounters a lexeme starting a comment, it invokes 
a meta action that increases the nesting count and returns (in the third 
component of its result) the comment lexer. 

— When the lexing process encounters a lexeme ending a comment, it triggers a 
meta action that decreases the nesting count and returns the standard lexer 
if the nesting count reached zero; otherwise, it returns the comment lexer. 

Note that this technique is a kind of cleaned up, side-effect free variant of the 
user-defined start states found in parser generators like lex. 

Like standard actions, we combine meta actions with regular expressions into 
lexers: 

e e a :: Rege — > Me a ^ Le e 

The library Lexers discussed here internally uses meta actions to keep track of 
positions in the presence of control characters in the following way {P i i is 
a triple composed from a file name, row, and column): 
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Le e 


:: Le e 




Le e 


= 




cha 


’\n’ ‘ e 


e a‘ e i e 


cjja cha 


’\r’ ‘ e 


e a‘ e i e 


cjj] cha 


’\r ‘ e 


e a^ f feed 


cjja cha 


’\t’ ‘ e 


e a‘ ab 


where 







e i e {fa e, 


) 


= ((/ a 


e, 


+ 1, 1), , N hi g) 


f feed If a e. 


) c ) 


= ((/ a 


e, 


, c + 1), , N hi g) 


ab {f a e, 


) c ) 


II 


e, 

hi g) 


, c -1- 8 — c ‘ 8), 



3.4 Lexing 

While performing lexical analysis, a lexer maintains a lexer state 
e Le e S a e = {S i g, P 1 1 ,) 

which is composed out of the remaining input string, the current source position, 
and a user-defined component — the latter is the same state that is transformed 
in meta actions. Given a lexer and a lexer state, the following function executes 
the lexical analysis and yields a token string:^ 

e ecLe e w Le e Le e S a e 

e ecLe e ([], -, -) = [] 

e ecLe e a e = case e O e a e of 

{N hi g, a e') - 

{J , a e') - 

The definition uses e O e to read a single lexeme from the input stream. If 
a token is produced, it is added to the resulting token stream. In any case, 
e ecLe e recurses to process the reminder of the input — in the case, where the 
just read token triggered a meta action, the lexer ' used in the recursion may 
differ from . The signature of e O e, which will be defined in detail later, is 

e O e :: Le e ^ Le e S a e {Ma be , Le e , Le e S a e ) 



e ecLe e ' 
: e ecLe e 



a e 



4 Table Construction and Lexical Analysis 

Given the interface of the previous section, it is not difficult to imagine a stan- 
dard combinator-based implementation (similar to [3]). The disadvantage of such 

^ In the actual implementation of the Lexers library, the function also returns the 
final lexer state as well as a list of error messages. 
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a naive implementation is, however, its low efficiency (see Section 5). As men- 
tioned, the standard method for making lexers more efficient is to transform the 
specification into the state transition table of a deterministic finite automaton. 

The main contribution of the present paper is a purely functional algorithm 
that on-the-fly constructs a DFA in a compressed table representation from reg- 
ular expressions. To improve the execution time for short inputs on big lexical 
specifications, only those parts of the table that are needed for lexing the input at 
hand are constructed. We achieve this by implementing the combinators build- 
ing regular expressions as a constructors of the transition table (instead of 
regarding a regular expression as a data structure, which is processed by a table 
construction function). More precisely, an expression of type {Le e ), which is 
a combination of regular expressions and actions, evaluates to a state transition 
table of a DFA that accepts exactly the lexemes specified by the regular expres- 
sions and has the actions in the automaton’s final states — the table construction 
algorithm is encoded in the combinators forming regular expressions. 

4.1 Table Representation 

In imperative algorithms the state transition table may be represented by a 
two-dimensional array indexed by the current automaton state and the current 
input symbol. For us, such a representation, however, has two problems: (1) The 
table tends to be sparse and (2) we like to incrementally refine the table. The 
sparseness of the table is, of course, also an interesting point in imperative lexers; 
therefore, the table is often stored in a compressed format after the off-line table 
construction is completed. However, this approach is not attractive in an on- 
line approach (i.e., when the table is constructed during lexing). Regarding the 
second point, our incremental table construction requires frequent updates of the 
transition table (until, eventually, the table for the whole lexical specification is 
completed), an operation that is expensive on big arrays in a purely functional 
programming style. 

Using the advanced data structures available in a functional language, we 
directly represent the state transition graph of the DFA, instead of using a con- 
ventional table representation. The state transition graph is a directed, cyclic 
graph — thus, a direct representation requires either a non-strict functional lan- 
guage or impure operations on mutable structures. Each node in the graph rep- 
resents a state of the DFA and each edge represents a state transition labelled 
with the input character triggering the transition. As we represent a DFA (not 
an NFA), there is at most one outgoing edge for each possible input character 
from each node. The final states of the DFA are those that are associated with 
an action and the initial state is the graph node that we use as the root. Overall, 
we represent a DFA (or lexer) by the following structure: 

da a Le e = S a e {Le Ac i ) [{Cha , Le e )] 

da a Le Ac i = Ac i {Ac i ) 

I Me a {Me a ) 

\ N Ac i 
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A S a e a c where a is different from N Ac i represents a final state. The 
continuation c is an association list of admissible transitions — i.e., for each ac- 
ceptable character in the current state, it contains the node in the graph that is 
reached after the associated character is read. For example, 

S a e ac [(’a’, i), (’c’, 2), (’d’, 3)] 

is a graph node that represents a state with three outgoing edges. On reading 
’a’, ’c’, and ’d’ the states 1, 2, 3, respectively, are reached. The action ac is 
executed before the choice between ’a’, ’c’, and ’d’ is made. 

The actual implementation of the library Lexers uses two different kinds of 
nodes (instead of only S a e) to represent states: One kind is used for states with 
only a few outgoing edges and the other for states with many outgoing edges. 
The former uses an association list, like in the above definition, but the latter 
uses an array to associate input characters with successor nodes. This increases 
the efficiency of the lookup in case of many outgoing edges, but does not alter 
the essence of the actual table construction algorithm. 

4.2 Basic Table Construction 

Before discussing the table-construction operators, we have to fix the type defi- 
nition of regular expressions. 

e Rege = Le e ^ Le e 

The essential point is that a regular expression is a lexer that can still be extended 
by another lexer to form a new lexer. In other words, if we have e , then, if 
a word matching the regular expression e is accepted, the rest of the input is 
handed to the lexer (which may be a final state associated with an action). 
In other words, we have to match an arbitrary prefix e before the automaton 
reaches (remember that expressions of type (Le e ) represent states of the 
overall automaton), whereas an individual node of the state transition graph 
specifies the consumption of only a single character, together with the associated 
transition. 

Given this, the definition of e, cha , and c> is straight forward. 



e 


:: Rege 


e 


= id 


cha 


:: Cha Rege 


cha c 


= A ^ S a e N Ac i 


(>) 


:: Rege Rege 


(>) 


= (0) 



[(c, )] 



Rege 



The functions id and (o) are the identity function and function composition, 
respectively. Thus, it immediately follows that e is the left and right neutral of 
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i>, and furthermore, that t> is associative. Properties required by formal language 
theory. 

The definition of e ac i requires a little more care: 

e ac i :: Rege ^ Ac i — > Le e 

e ac i e a = e {S a e {Ac i a) []) 

It adds a final state containing the given action a and no transitions to the 
regular expression. 

The most interesting combinators are alternatives, because they introduce 
indeterminism when constructing an NFA; thus, as we directly construct a DFA, 
we immediately have to resolve this potential indeterminism. To avoid dealing 
with the same problems in the two combinators t|<i and cHa, we define i>|<i in terms 
of cHa: 

(c^) :: Rege — > Rege — > Rege 

ei>|<ie' = A ^ e cH^e' 

This essentially means that, given a regular expression ( ei cjd e2)> 63, the con- 
tinuation of 6i and 62 is the same, namely 63. In other words, in case of 
an alternative, independent of which branch we take, we reach the same suffix. 
Given this definition, cjd is associative and commutative if cHa is. The latter we 
define as 

(cjjci) :: Le 6 ^ Le e ^ Le e 

{S a e a c) ^ {S a e a' c') = S a e { i Ac i a a') {acc (cHa) (c -H- c')) 

The function combines transitions and actions separately. The two transition 
tables c and c' are combined by {acc (cjjci) (c -H- c')), which concatenates the 
association lists c and c' and applies the auxiliary functions acc to replace 
all pairs of conflicting occurrences (c, ) and (c, ') by a new pair (c, ') (we 

omit the precise definition of acc ; it is slightly tedious, but does not present 
new insights). Finally, the following function combines two actions: 

i Ac i :: Le Ac i — > Le Ac i Le Ac i 

i Ac i N Ac i a' = a' 

i Ac i a N Ac i = a 

i Ac i - _ =6 ’’Lexers: Ambiguous action!” 

If both of the two states have an action, i Ac i raises an error; it implies 
that there is a lexeme that is associated with two actions, but we can only 
execute one of them. This indicates an error in the lexical specification. From 
the definition of i Ac i and the associativity and commutativity of -H-, we 
can easily deduce the associativity and commutativity of c(|ci, and thus, t|<i. 

As an example for the use of c|)ci consider 

{cha 'dJ ^ e a i ‘ aci)\^{cha ’a’ > cha ’h’ ‘ e a i ‘ 062) 
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The two regular expression have a common prefix; thus, the initial state of the 
resulting lexer only has a single transition for the character a. The following 
state contains the action aci — making it a final state — but also contains a tran- 
sition for b. The third state contains only the action ac 2 , no further transition 
is possible. Overall, we get the lexer 

S a e N Ac i [('a', S a e ac\ [('&', Sac ac 2 [])])] 

This example illustrates how an action can get in the middle of a more complex 
lexer. In this example, it may appear as if the choice between aci and ac 2 were 
indeterministic when accepting ab; however, the principle of the longest match, 
which we shall discuss in Section 4.4, disambiguates the choice and requires the 
lexer to execute only ac 2 - 

At this point, the reason for a design decision made earlier in the definition 
of the Le e data type also becomes clear. When considering a single regular 
expression and action, it might seem reasonable to pair the action with the root 
of the transition graph; instead of allowing an action in every state and putting 
the initial action at the tips of the structure representing the lexer. As we just 
saw, when two lexers are disjunctively combined, actions may may move in the 
middle of the transition graph and the exact location of an action within the 
graph becomes important — it is not sufficient to collect all actions at the root 
of the graph. 

4.3 Cyclic Graphs 

The remaining combinators for regular expressions, ®, 0, and ?, are build from 
the basic combinators that we just discussed. The definition of ? is straight 
forward: 

(?) :: Rege — > Rege Rege 

el? e2 = ( el > e2) cjd e2 

The recursive behaviour of ® and ®, however, requires some additional 
thought. In a first attempt, we might define ® as follows: 

(®) :: Rege Rege — > Rege 

el® e2 = let e/ = ( elc> e/cj)^e)in e f \> e2 

The recursion is realised by the local definition of e /, which can either be the 
empty word e, or it can be a word matched by el and followed again by e/, 
until finally, e/ is followed by e2. In other words, we can use el zero, one, 
or more times before continuing with e2. So, the above definition is correct, 
but unfortunately, it is operationally awkward. It does not create a cyclic graph, 
but produces an infinite path, repeating el. As the path is constructed lazily, 
the definition works, but, for the construction of the state transition graph, it 
consumes memory and time proportional to the length of the accepted lexeme, 
rather than the size of the regular expression. 
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Fortunately, we can turn this inefficient definition by equational reasoning 
into an efficient, but harder to understand definition: 

let ef = ( el t> efckielin e f t> e2 
= {unfold (^)l 

let ef = ( el [> ef) cfja e in e/> e2 
= {unfold e and beta reduction} 

let ef = ( ef[> ef) cj{i in ef> e2 
= {unfold (>) and beta reduction} 

let ef = el(e/)c|{iine/[>e2 
= {unfold (>)} 

let e / = el ( e / ) cjja in A ' — > e / ( e2 ') 

= {float let inside lambda} 

X ' ^ let ef = el ( e/ ) c|{j in e / ( e2 ') 

= {lambda dropping} 

A ' ^ let = e2 ef = el e/c|{] in ef 
= {inlining} 

A ' — *■ let ef= el e/ cjja ( e2 ') in ef 

The reason for the different behaviour of the initial and the derived definition 
is that in the original definition ef has type {Rege ), which is a functional, 

whereas in the derived definition, it has type (Le e ), which is the datatype 

in which we want to create the cycle. Note in reference to the remark made at 
the end of Subsection 3.1 that this calculation depends on ® being a binary 
operator (and not an unary postfix operator). 

It remains the definition of 0, which is simple when expressed in terms of ®: 



(®) :: Rege — > Rege — > Rege 

el® e2 = el [> ( el® e2) 



4.4 Lexing 

Given the state transition graph, we have to implement the lexing process by 
a traversal of the graphical DFA representation. Lazy evaluation of the graph 
ensures that only those portions of the table that are necessary for lexing the 
input at hand are actually evaluated and that each part of the graph is evaluated 
at most once. In Subsection 3.4, the definition of e ecLe e used a function 
e O e, which reads a single lexeme. In the following, we encode the graph 
traversal in e O e as a tail recursive function over the input string. The main 
complication in this function is the implementation of the principle of the longest 
match, i.e., we cannot take the first action that we encounter, but we have to 
take the last possible action before the automaton gets stuck. Therefore, during 
the traversal, we keep track of the last action that we passed along with the 
lexeme recognised up to this point. When no further transition is possible, we 
execute the last action on the associated lexeme; if there was no last action, we 
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encountered a lexical error. The concrete definition of e O e makes use of the 
recursive function c ec , which collects all characters of the current lexeme. In 
addition to the current lexer and state, it maintains an accumulator for collecting 
the lexeme (third argument) and the most recently encountered action (fourth 
argument). The latter is initially an error, i.e., before the first valid action is 
encountered during lexing. 

e O eT e = {Ma he , Le e , Le e S a e ) 

e O e w Le e Le e S a e O eT e 

e O e a e = c ec ae””(e ’’Lexical error!”) 

A value of type O eT e comprises all information associated with a lexeme: 
possibly a token and the lexer to be applied and state reached after reading the 
lexeme. 

The implementation of c ec distinguishes three cases, dependent on the 
next input symbol and the transition table c : 

c ec :: Le e Le e S a e ^ S i g ^ O eT e 

^ O eT e 

c ec {S a e a c ) a e@(c , , ) e e e a = 

let a ' = ac i a a e e e e a 

in 

case c of 

D ^ ' 

(c : c ') ^ case c c of 

N hi g —> a ' 

J ' c ec ' {c ' , ,)(eee4T [c]) a ' 

We use the auxiliary function ac i to compute the most recent action result 
a '.It applies actions to the current lexer state and the recognised lexeme; we 
shall return to its definition below. To decide how to react to the current input 
character c, we perform a in the transition table c If the character is 

not in the transition table (i.e., there is no valid transition in the DFA for the 
current input symbol), we use the most recent result of an action, namely a ' . 
Otherwise, the automaton makes a transition to the state ', which is associated 
with the current input symbol c in the transition table; furthermore, the current 
lexeme is extended with the character just read. 

The function ac i deals with the three possible cases of the data type 



Le Ac i 


as follows: 








ac i 


:: Le Ac i 
0 eT e 


Le e S a e 


S i g - 


^ 0 eT 


ac i 


N Ac i 


a 


= a 




ac % 


{Ac i a) (c , 


, ) e e e _ 


= 




(a 


e e e, , (c , ad 


a ceP e e 


e, )) 





The function lookup Eq a ^ a ^ [(a, 6)] — > Maybe b is from the Haskell prelude. 
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ac i {Me a f) (c, ,)eee_ = 
let ( {ad a ceP e e e) 

in 

{N hi g, f Ma he (c , ')) 

The function ad a ceP adjust the current position by the length of the given 
lexeme (its definition is not given, as we did not fix a concrete representation 
for positions). In the third equation of ac i (the case of a meta action), the 
function of the meta action is applied to yield a new position ', user-defined 
state ' , and possibly a new lexer ' . The function / Ma be selects the new 
lexer if given; otherwise, it uses the current lexer It should be clear that 
keeping track of the last action in the fourth argument of c ec and ac i 
realises the principle of the longest match and, by means of lazy evaluation, 
delays the execution of the candidate actions until it is known which one is the 
last. 

Accumulating the lexeme by appending individual list elements with -H-, as 
in the above definition of c ec is inefficient. In the Lexers library, difference 
lists (similar to Sh S from the Haskell prelude) are used, which allow constant 
time appends. 



5 Benchmarks 

The performance of the presented technique was measured by coding a lexer for 
the programming language C with the Lexers library as well as implementing 
a ha dc ded lexer for the same set of regular expressions. The comparison be- 
tween the two gives an estimate of the overhead incurred when using the more 
convenient Lexers library. The handcoded lexer implements the DFA using pat- 
tern matching on the first character of the remaining input. It carries the same 
overhead as Lexers for keeping track of token positions; there is still scope for 
optimisations, but they are not expected to make a big difference. The programs 
were compiled with the Glasgow Haskell Compiler (GHC), version 4.04, using 
optimisation level -0. The experiments were conducted on a SOOMhz Celeron 
processor under Linux. In the Haskell source of the library and the specification 
of the C lexer, no GHC-specific optimisations or language features were used; 
the input string was naively represented as a cons list of characters. The bench- 
mark input to the lexer is (a) an artificial code, which contains a struct with 10 
fields a 1000 times, and (b) the header file of the GTK-I- GUI library after being 
expanded by a standard C pre-processor. Both files are about 200 kilobyte, i.e., 
they are real stress tests, not toy examples. The results are summarised in the 
following table (they do not include I/O time and are the best results from three 
runs on an unloaded machine): 

These results show that for large input, the optimising lexer combinators 
are in the same ball park as a handcoded lexer, which needs about 70% of the 
execution time. 

® Haskell’s standard library Maybe defines fromMaybe :: a ^ Maybe a ^ a. 
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Lexers handcoded 



input 


size (byte) 


time (sec) 


tokens/sec 


time (sec) 


tokens/sec 


% 


GTK-t 


233,406 


1.99 


16,550 


1.52 


21,668 


76% 


structs 


207,000 


2.36 


25,338 


1.69 


35,384 


72% 



6 Related Work 

In comparison to off-line scanner generators, the added ffexibility and ease of use 
of the presented approach comes for increased startup costs (as the graph has to 
be build) and the inability to perform some optimisations on the automaton (like 
computing the minimal automaton). However, lazy evaluation avoids the startup 
costs partially if the given input requires only some of the regular expressions of 
the lexical specification. 

Regarding related work, the main part of the paper made the relation to 
the automata theory underlying scanner generators clear. It would be interest- 
ing to establish a formal correspondence between the DFA created by the lexer 
combinators and those produced by the various off-line automata construction 
algorithms. I do not have a formal result yet, but believe that the automata 
is the same as the one constructed by the algorithm from the dragonbook [1] 
that constructs an DFA directly from a set of regular expression. Furthermore, 
the dragonbook [1, p. 128] mentions a technique called a an e a a- 
i . It also constructs a transition table at runtime, but the aim is to avoid 
the state explosion that can occur during the generation of a DFA from regu- 
lar expressions — in the worst case, the number of states of the DFA can grow 
exponentially with the size of the regular expression. In this technique, state 
transitions are stored in a cache of fixed size. In case of a cache miss, the tran- 
sition is computed using standard algorithms and stored in the cache; it may 
later be removed from the cache if it is not used for a while and many other 
transitions are needed. This technique, however, makes essential use of mutable 
data structures and is substantially different from the presented one, in both its 
aim and working principle — it was developed for the use in search routines of 
text editors. 

Swierstra and Duponcheel’s [7] parser combinators provided the inspiration 
for searching for a related technique that works for lexical analysis. Like their 
approach is based on the theory of SLL(l) stack automata, the present technique 
is based on the theory of finite state automata. The technique itself, however, is 
significantly different. 



7 Conclusion 

We have discussed an approach to lexical analysis in a lazy functional language 
that combines the ease of use and flexibility of combinator libraries with the 
efficiency of lexical analyser generators. In this approach, a lexical analyser is 
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specified as a set of pairs of regular expressions and actions using functions 
from a combinator library. The combinators are smart constructors, building a 
state transition graph of a deterministic finite state automaton implementing 
the regular expressions. The graph is lazily constructed during lexing and makes 
use of cycles to represent the recursive combinators ® and 0. 

It is worth noting that the discussed technique makes essential use of laziness 
and can be regarded as a practical example of the usefulness of lazy evaluation. 
First of all, non-strictness allows to significantly optimise the implementation 
of recursive combinators by exploiting cyclic structures. Furthermore, the lazy 
construction of the state transition graph minimises startup costs when the input 
does not use all regular expressions of the lexical specification. However, the use 
of cyclic structures is definitely an advanced feature of Haskell, which requires 
some experience to use; we showed how equational reasoning can help to compute 
an efficient solution that makes use of cyclic structures from a less efficient, but 
easier to understand implementation. Furthermore, the implementation of the 
principle of the longest match is simplified by using lazy evaluation to keep track 
of the last action. 

The use of a lazy list of characters for the input to the lexer is definitely not 
the most efficient choice. However, it simplifies the presentation and only the 
function c ec depends on the representation of the input. It should not be hard 
to adapt it to a more efficient form of reading the character stream. Furthermore, 
it might seem attractive to represent lexers as monads; this presents, however, 
some technical challenges, similar to those reported in [7]. 

Regarding future work, it would be interesting to investigate whether the 
whole algorithm could be formally derived from the underlying automata theory, 
which was only informally described in this paper. 

Ac edge e . I am indebted to Simon Peyton Jones for a number of sug- 
gestions that helped to improve this paper and the Lexers library considerably. 
Furthermore, I am grateful to Gabriele Keller and the anonymous referees for 
their helpful comments and suggestions on the paper. Finally, I like to thank 
Roman Lechtchinsky for his feedback on the Lexers library. 
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Abstract. Parsing has been a traditional workbench for showing the 
virtues of declarative programming. Both logic and functional program- 
ming claim the ability of writing parsers in a natural and concise way. We 
address here the task from a functional-logic perspective. By modelling 
parsers as non-deterministic functions we achieve a very natural manner 
of building parsers, which combines the nicest properties of the functional 
and logic approaches. In particular, we are able to define parsers within 
our framework in a style very close to that of functional programming 
parsers, but using simpler concepts. Moreover, we have moved beyond 
usual declarative approaches to parsers, since the functional-logic parsers 
presented here can be considered as truly data values. As an example of 
this feature we define a function that detects ambiguous grammars. 



1 Introduction 

The problem of syntax analysis or has been one of the most thoroughly 

studied issues in computer science. Its wide range of applications, from compiler 
development to natural language recognition, is enough to attract the attention 
of any programming approach. This has also been the case for logic program- 
ming (LP, in short) and functional programming (FP, in short), and the parsing 
problem constitutes in fact one of the favorite fields for exhibiting the virtues 
of declarative programming, looking for a straightforward way of representing 
parsers as proper components of the language. This has been achieved by con- 
sidering , usually represented by means of language 

mechanisms adapted to simulate grammar rules (e.g. BNF rules). 

There is a more or less standard approach [19] to the construction of parsers 
in LP, which is based on a specific representation for grammars, the so-called 

’s are not logic programs, although they 
are readily translated to them. With ’s, one can hide the details of handling 
the input string to be parsed, which is passed from parser to parser using the LP 
technique of . . Parsing in LP benefits from the expressive power of 

non-determinism, which handles almost effortlessly the non-deterministic essence 

* Work partially supported by the Spanish CICYT (project TIC98-0445-C03-02/97 
’’TREND”) and the ESPRIT Workin g Group 22457 (CCL-II). 

A. Middeldorp, T. Sato (Eds.): FLOPS’99, LNCS 1722, pp. 85-99, 1999. 
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of grammar specifications. In the case of ambiguous grammars this means that 
multiple solutions are automatically provided where possible. The use of logi- 
cal variables and unification are also useful in LP parsers. They ease the con- 
struction of output representations, which is carried out explicitly by using an 
input/output extra argument. Moreover, multiple modes of use are allowed, i.e. 
LP parsers can be regarded as as well as recognizers of sentences, and 

parsers for some context sensitive languages can be easily defined. 

The main contribution of FP parsers are the so called , combi- 

nators [13,6]. In addition, the use of (see [20]), specially in combination 

with the [14] gives a very appealing structure to the parsers. 

Many efforts have been done in the last decade in order to integrate LP and 
FP into a single paradigm, (FLP in short, see [10] 

for a survey). As any other paradigm, FLP should develop its own programming 
techniques and methodologies, but little work has been done from this point of 
view. In this paper the problem of developing FLP parsers in a systematic way 
is addressed, trying to answer the question: can FLP contribute significantly by 
itself (not just mimicking LP or FP) to the task of writing parsers? 

We will show how a suitable combination of LP and FP features leads to 
parser definitions as expressive as FP parsers, but based on simpler concepts. 
Moreover, we have moved beyond current FP and LP approaches to parsers, for 
the FLP parsers presented here can be considered as . Thus, 

interesting properties of the represented grammar, such as ambiguity, can be 
easily examined in our purely declarative setting. We stick to a view of FLP 
whose core notion is that of . . .A framework for such 

an approach is given in [7], which is extended to cope with higher-order features 
in [8], and polymorphic algebraic types in [2]. 

The rest of the paper is organized as follows. In the next section we will 
briefly describe the specific functional- logic language we are going to use: TOy. 
Section 3 examines the main characteristics of parsers in LP and FP, choosing 
the best features of each paradigm to define our model of FLP parsers. Section 4 
is devoted to the definition of some basic parsers and parser combinators. These 
functions are the basic pieces we will use to build more complicated parsers, like 
the examples presented in Section 5. In Section 6 we show how the ‘intensional’ 
view of functions allows T Oy programs to manipulate parsers as truly data 
values. In particular, a suitable function for parsers in TOy is defined, to- 
gether with an application of such function used to detect ambiguous grammars. 
Finally, Section 7 summarizes some conclusions. 

2 A Succinct Description of 'TOy 

All the programs in the next sections are written in TOy [17], a purely declar- 
ative functional-logic language with solid theoretical foundations, which can be 
found in [7,8,2]. We present here the subset of the language relevant to this 
work (see [3] for a more complete description and a number of representative 
examples). 
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A Toy program consists of , and defini- 
tions, and rules for defining . Syntax is mostly borrowed from Haskell 

[12], with the remarkable exception that variables begin with upper-case letters 
whereas constructor symbols use lower-case, as function symbols do. In par- 
ticular, functions are and the usual conventions about associativity of 

application hold. 

like data nat = zero j sue nat, define new (possibly 
polymorphic) and determine a set of for each 

type. The set of all data constructor symbols will be noted as ( " for all 

constructors of arity n). 

T, r',.-- can be constructed types, tuples (ti,...,t„), or functional 
types of the form r ^ r'. As usual, ^ associates to the right. TOy provides 
predefined types such as [A] (the type of polymorphic lists, for which Prolog 
notation is used), bool (with constants true and false), int, real for inte- 
ger and real numbers, or char (with constants ’a’,’b’, ...). defini- 

tions like type parser A = [A] — > [A] are also allowed. Type alias are simply 
abbreviations, but they are useful for writing more readable, self-documenting 
programs. Strings (for which we have the definition type string = [char] ) 
can also be written with double quotes. For instance, "sugar" is the same as 
[’s’ , ’u’ , ’g’ , ’a’ , ’r’] . 

The purpose of a TOy program is to define a set of functions. Each / G 

comes with a given which expresses the number of arguments 

that must be given to / in order to make it reducible. We use " for the set 
of function symbols with program arity n. Each / G " has an associated 
principal type of the form t\ ^ ^ Tm ^ t (where r does not contain ^). 

Number m is called the of / and well-typedness implies that m > n. 

As usual in functional programming, types are inferred and, optionally, can be 
declared in the program. 

With the symbols in C'S' and FS, together with a set of variables X, Y, 
. . ., we form more complex expressions. We distinguish two important syn- 
tactic domains: and . are of the form e ::= 

AT I c I / I (ei,...,e„) | (e e'), where c G , / G .As usual, applica- 
tion associates to the left and parentheses can be omitted accordingly. Therefore 
e ei . . . e„ is the same as ((...( (e Ci) 62 ). . .) e„). Of course expressions are as- 
sumed to be well-typed. are a special kind of expressions which can be 

understood as denoting data values, i.e. values not subject to further evaluation, 
in contrast with expressions, which can be possibly reduced by means of the rules 
of the program. They are defined hy t ::= X \ (ti, . . . , t„) | c 
where c G n < m, f € n < m. Notice that partial applications (i.e., 

application to less arguments than indicated by the arity) of c and / are allowed 
as patterns, which are then called , because they have a functional 

type. Therefore function symbols, when partially applied, behave as data con- 
structors. HO patterns can be manipulated as any other patterns; in particular, 
they can be used for matching or checked for equality. With this . 
point of view, functions become ‘first-class citizens’ in a stronger sense that in 
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the case of ‘classical’ FP. This treatment of HO features is borrowed from [8] 
and will constitute an useful tool in Sect. 6. Each function f G ” is defined by 
a set of conditional rules of the form f t\ . . .tn = e <1= ei == e^, . . . , == e'j. 

where {t\ . . . tn) forms a tuple of linear (i.e., with no repeated variable) , 

and e, Cj, e' are . No other conditions (except well-typedness) are im- 

posed to function definitions. The notation VSpat, with V a variable name and 
pat a valid pattern, is allowed for the patterns U. It represents the so-called 

: every occurrence of V in the body or the conditions of the rule will be 
automatically replaced by pat. 

Rules have a conditional reading: / t\ . . .tn can be reduced to e if all the 
conditions Ci == e^, . . . , == e). are satisfied. The condition part is omitted if 

k = 0. The symbol == stands for , which is the suitable notion (see 

e.g. [10]) for equality when non-strict functions are considered. With this notion 
a condition e == e ’ can be read as: e and e ’ can be reduced to the same pattern. 
When used in the condition of a rule, == is better understood as a constraint (if 
it is not satisfiable, the computation fails), but the language contemplates also 
another use of == as a function, returning the value true in the case described 
above, but false when a clash of constructors is detected while reducing both 
sides. As a syntactic facility, TOy allows repeating variables in the head of rules 
but in this case repetitions are removed by introducing new variables and strict 
equations in the condition of the rule. As an example, the rule f X X = 0 would 
be transformed into f X Y = 0 -4= X == Y. 

In addition to ==, T Oy incorporates other predefined functions like the arith- 
metic functions +,*, . . . , or if _then and if _then_else, for which the more usual 
syntax if _ then _ and if _ then _ else _ is allowed. Symbols ==, + ,* are 
all examples of . New operators can be defined in T Oy by means 

of. declarations, like infixr 50 ++ which introduces ++ (used for list con- 
catenation, with standard definition) as a right associative operator with priority 
50. , or partial applications of infix operators, like (==3) or (3==) are 

also allowed. 

are seen in T Oy as true- valued functions. is al- 

lowed, according to the syntax p ...t„ : — bi, . . . ,bm which is simply a syntactic 
sugar for the functional rule p = true bi == true, . . . ,bm == true. 

A distinguishing feature of TOy, heavily used throughout this paper, is 
that no confluence properties are required for programs, and therefore functions 
can be . . . , i.e. return several values for given (even ground) ar- 

guments. For example, the rules coin = 0 and coin = 1 constitute a valid 
definition for the 0-ary non-deterministic function coin. A possible reduction 
of coin would lead to the value 0, but there is another one giving the value 1. 
The system will try the first rule first, but if backtracking is required by a later 
failure or by request of the user, the second one will be tried. Another way of 
introducing non-determinism is by putting variables in the right side of the 
rules, like in z_list = [0|L] . Although in this case z_list reduces only to [0|L], 
the free variable L can be later on instantiated to any list. Therefore, any list of 
integers beginning with 0 is a possible value of z_list. Our language adopts the 
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so called , . semantics for non-deterministic functions. Call-time 

choice has the following intuitive meaning: given a function call i „ , one 
chooses some fixed value for each of the i before applying the rules for . As 
an example, if we consider the function double X = X+X, then the expression 
(double coin) can be reduced to 0 and 2, but not to 1. As it is shown in [7], 
call-time choice is perfectly compatible with non-strict semantics and lazy eval- 
uation, provided , is performed for all the occurrences of a variable in the 

right-hand side of a rule. 

Computing in TOy means solving , which take the form ei == e{, . . . , 
6k == e'f., giving as result a substitution for the variables in the goal making it 
true. Evaluation of expressions (required for solving the conditions) is done by a 
variant of lazy narrowing based on the so-called (see [16] ) . 

With respect to higher-order functions, a first order translation following [9] is 
performed. 

3 Our Model of Parsers 

In declarative programming we aim at defining parsers denoting the structure of 
the underlying grammar. Consider the following production, written in extended 
BNF syntax <expr> : := <term><plusjninus><expr> j <term>. 

In order to translate properly this rule into a declarative program, we must come 
out to some decisions: 

(i) How to represent the alternative of parsers, denoted in the rule above by the 
symbol |. 

(ii) How to represent a sequence of parsers like <term><plusjninus><expr>. 

(iii) Moreover, the parser expr should not only recognize when a sentence belongs 
to the underlying formal language. It should also return a suitable representation 
of the parsed sentence. Hence we must take care of representations when deciding 
the final structure of parsers. 

Before considering these questions in our setting, we will briefly overview 
the characteristics of parsers in the two main declarative paradigms. In FLP we 
could remain attached to either the FP or the LP point of view, but we will show 
how a careful combination of both perspectives leads to the same expressiveness 
with simpler parser definitions. In the following discussion the LP point of view is 
represented by Prolog, while functional parsers are those of Haskell as described 
in [6,20,14]. 

3.1 Review of LP and FP Parsers 

As common ground, both paradigms represent the sentence to be parsed as a 
list of terminals. This list is provided as an input parameter to the parser, which 
tries to recognize a prefix returning the non-consumed part. This part, the output 
sentence, is then supplied as input for the next parser connected in sequence. 
Now we summarize some of the main differences between both approaches with 
respect to the points (i), (ii) and (iii) mentioned above. 
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In Logic Programming all the values need to be arguments of some pred- 
icate. Thus the input and output sentences and the representation must be 
parameters of the parser predicate. In addition to that: 

(i) The non-deterministic nature of grammar specifications is easily handled in 
Prolog, just representing different alternatives through different rules for the 
same predicate. The built-in mechanism of Prolog will initially choose the first 
rule. If it fails, or more solutions are requested by the user, the next alternative 
is tried by means of 

(ii) Input and output lists are explicit arguments when writing parsers in se- 
quence, as witnessed by the Prolog definition: expr(I,0) :— term(I , Auxl) , 
plus_minus(Auxl,Aux2) , expr(Aux2,D) . This notation is rather tedious, and 
is avoided in Prolog systems by introducing a new formalism which conceals the 
passing of parameters, namely the DCG’s. Using DCG’s one can write the more 
appealing rule expr — > term, plus_minus, expr. 

(iii) The representation also needs to be an argument, usually used as an output 
value. However, in this case, it is not a problem but an advantage, as it permits 
defining explicitly the construction of new representations from those of their 
components, as in the definition: 

expr(R) > term(T) , [+] , expr(E), {R is T+E} . 

expr(R) > term(R) . 

In Functional Programming, input values must be parameters of func- 
tions, and output values must be results of evaluating functions. Therefore, the 
input sentence is the only input parameter of a parser function, while the repre- 
sentation and the output sentence are its result value, usually in the shape of a 
pair (repr,sent). The solutions provided to the questions of the points (i), (ii) 
and (iii) mentioned above are: 

(i) Since non-determinism is not a built-in mechanism of functional languages, 
the alternative of parsers need to be ‘simulated’. This problem can be solved 
by collecting in a list the results of trying each alternative, hence representing 
different alternatives through different elements of the list. In such a context, an 
empty list means that the parser has failed. Therefore the type of FP parsers is 
type Parser rep sym = [sym] — > [ (rep,[sym]) ]. The alternative operator 
can be defined now as: (p <|> q) s = (p s) -|— I- (q s). 

(ii) The sequence of parsers can be defined by a suitable HO combinator <*> , 
which hides the passing of the output sentence of each parser as input sentence of 
the next one. However, the definition of <*> depends also on the representation, 
as explained in the following point. 

(iii) Often the representation of a parser function must be defined in relation 
to the representations of its components. In FP this is achieved through the 
definition of the sequence operator: 

(p<*>q) s= [ (y,s’0 I (x,s0^ps, (y,s’0^ (qx) s’ ] which 
has to deal with representations and not only with output sentences. In order to 
build the parser representation, the operator <*> takes out the representation 
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of the parser p, which is used as input argument for the function q, usually a 
lambda abstraction. 

These operators, together with suitable declarations of priority and associa- 
tivity, allow us to define 

expr = term <*> At ,plus_minus <*> Ao . expr <*> Ae. return (o t e) 
<|> term 

where t stands for a number representing the evaluation of term, o stands for a 
functional value (-1- or — ) and e denotes the result of evaluating the expression of 
the right-hand side. Function return can be defined as return x s = [(x,s)]. 
If we consider parsers as (see [20]), this notation can be abbreviated by 

using the [14], which is provided as a syntactic sugar to combine 

monads in sequence: 

expr = do { t <— term, o 4— plusjninus, e <— expr, return (o t e)} 
< j > term 



3.2 Parsers in ^ Oy 

Now we are ready to define our model of parsers. In T Oy , we distinguish between 
parsers without representation, which we will call simply and 

. Parsers in TOy have the simple type: 

parser Sym = [Sym] [Sym] 

that is, they take a sentence and return the non-consumed part of the sentence. 
Usually Sym stands for char, but in section 5.3 we will see an example of a 
language whose sentences are lists of integer numbers. 

(i) The solution for the alternative of parsers provided by LP is simpler than 
that of FP. However, the introduction of the HO combinator <]> in FP permits 
a more expressive notation. In T Oy we can combine the expressiveness of HO 
combinators of FP with the simpler definitions allowed by non-deterministic 
features of logic languages: A suitable non-deterministic HO combinator < j > 
can be defined in T Oy as 

(P <]> Q) Sent = P Sent 
(P <]> Q) Sent = Q Sent 

Therefore, parsers in out setting will be non-deterministic functions. This notion 
reflects the non-deterministic essence of grammar definitions and has been used 
for theoretical purposes already (see [15]). 

(ii) The definition of a sequence combinator <*> in FP avoids the introduction 

of mechanisms such as DCG’s. However this definition is complicated 

as it must take care of representations. In TOy the combinator <*> can be 
defined as: (PI <*> P2) I = P2 01 -<= PI I == 01 that is, the first parser 
PI is applied to the input sentence I, and then the second parser is applied to 
the value 01 returned by PI. 
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(iii) The solution provided by LP for handling representations is much simpler 
than the FP solution. Therefore, the representations in TOy will be extra (usu- 
ally output) arguments of the parser functions. The type of parsers with represen- 
tation is: type parserjrep Rep Sym = Rep ^ parser Sym . Observe how- 

ever that the type of parsers in FP (type Parser r s = [s] ^ (r,[s]))more 
clearly reflects the usual intended mode of the parameters. Nevertheless we 
choose the type above because it will lead to simpler parser definitions. It is 
worth noticing that if P is of type parserjrep then P R will be of type parser. 
Hence, we do not need to define an special sequence combinator for parsers with 
representation: the operator <*> can also be used in such situations. 

An alternative combinator for parsers with representation is, however, nec- 
essary. It can be easily defined as: (PI <||> P2) Rep = PI Rep <|> P2 Rep, 
meaning that the alternative of values of type parserjrep is converted into an 
alternative of values of type parser as soon as the representation Rep is provided. 

As a convenient tool for attaching representations to parsers we define the com- 
binator » , which converts a parser in a parserjrep, as: 

( » ) : : parser A ^ B ^ parserjrep B A 
(P » Expr) R I = 0 -4= P I == 0, Expr == R 

That is, the variable R standing for the representation is matched with the ex- 
pression Expr after applying the parser to the input sentence. 

Before ending this section we declare the precedence of the combinators 
<*> , », <|> and < I >, together with their associativity. These defini- 

tions allow one to omit unnecessary parentheses. 

infixr 40 <*> infixr 30 » infixr 20 <|>, <||> 

4 Simple Parsers and Combinators 

In this section we introduce a set of simple parsers and parser combinators 
that we will use to build more complicated parsers later. They are also our first 
examples of parsers in TOy and are based on the FP parsers described in [6,13]. 

The simplest parser, empty, recognizes the empty sentence, which is a prefix 
of every sentence. Hence, empty always succeeds without consuming any prefix 
of its input: 



empty: : parser A 
empty S = S 

Parser terminal T recognizes a single symbol T, failing otherwise. 

terminal:: A ^ parser A 
terminal T [T|L] = L 
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Sometimes it is desirable to recognize not a fixed symbol, but any one fulfilling 
a given property P. Function satisfy accomplishes this aim: 

satisfy: : (A ^ bool) ^ parserjrep A A 
satisfy P X [X|L] = if P X then L 

Notice that satisfy P is a parser with representation, as it returns as represen- 
tation the recognized terminal X. 

In section 3 we introduced some parser combinators: <*> , <|> and » . 
Here we introduce two new ones: star and some. Combinator star represents 
the repetition zero or more times of the parser with representation P. The rep- 
resentation retrieved by star P is a list collecting the representations of each 
repetition of P. 



star:: parserjrep A B ^ parserjrep [A] B 
star P = P X <*> (star P) Xs » [X|Xs] 

<ll> empty » [ ] 

Function some represents the repetition at least once of the same parser, and can 
be defined easily in terms of star: some P = P X <*> star P Xs » [X|Xs] . 



5 Examples 

This section is devoted to present some examples of parsers in TOy. We in- 
tend to show how, by means of the simple basic parsers and parser combinators 
defined before, we achieve the same expressiveness as FP parsers. Furthermore, 
interesting capabilities of LP parsers, such as the possibility of generating sen- 
tences instead of recognizing them are preserved. 



5.1 Arithmetic Expressions 

The parser shown in figure 1 recognizes arithmetic expressions made from in- 
teger numbers, the operators , , , and parentheses. The main parser is 

expression which returns as representation the numeric value of the expression. 
The first rule says that an expression is either a term followed by an operator 
or and ended by another expression or simply a term. In the first case the 
combinator » shows that the representation of the expression is the result of 
applying the representation of the operator to those of the two other components. 
In the second case the representation of the expression is the representation of 
the term. Among the rest of the parsers, we must point out the introduction of a 
function numeric_value which converts a string of digits into its numeric value. 
The definition of this function relies on the standard functions foldll and map: 
numeric_value L = foldll ((+).(10*)) (map val L) and constitutes a typ- 
ical example of how FTP inherits the higher-order machinery usual in FP. For 
instance, the goal expression R "(10+5*2)/4" == [] succeeds with R == 5. 




94 



Rafael Caballero and Francisco J. Lopez-Fraguas 



expression 


— 


term T <*> plusjninus Op <*> expression E » 


(Op T E) 




<il> 


term 






term 


= 


factor F <*> prod_div Op <*> term T » (Op F 


T) 




<ll> 


factor 






factor 


= 


terminal ’ ( ’ 


<*> expression E <*> terminal ’)’ 


» E 




<ll> 


num 






plusjninus 


= 


terminal ’+’ 


» (+) 






<ll> 


terminal 


» (-) 




prod_div 


= 


terminal 


» (*) 






<l> 


terminal ’/’ 


» (/) 




mim 


= 


some digit L 


» (numeric_value L) 




digit 




satisfy is_digit 





Fig. 1. Parser for arithmetic expressions 



5.2 Parsers as Generators 

Owing to the possibility of including logical variables in goals, FLP parsers may 
be regarded as generators as well as recognizers. Consider for instance the parser 

p = empty <|> a <|> b <|> a <*> p <*> a <|> b <*> p <*> b 

a = terminal ’a’ 
b = terminal ’b’ 

which recognizes the language of the palindrome words over the alphabet S = 
{a, 6}. Using this parser we may ‘ask’ for sentences of length two in the language 
recognized by p: p [X,Y] == []. Two answers are retrieved, namely X=’a’ , 
Y=’a’ and X=’b’ , Y=’b’, meaning that and are the only words of 

length two in this language. 

5.3 Numerical Constraints 

The growing interest in languages representing spatial relationships has intro- 
duced the study of in relation to the parsing problem. Here 

we show a very simple but suggestive example of how our parsers can integrate 
numerical constraints easily. 

Suppose we are interested in a parser for recognizing , regarding a box 
as a rectangle whose sides are parallel to the X and Y axes. The terminals 
of the language will be pairs of integers representing points in the plane, and 
a valid sentence will be a sequence of four points standing for the corners of 
the box, beginning with the lower-left and following anti-clockwise. The desired 
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representation is a pair of points representing the lower-left and the upper-right 
corners of the box. 

box:: parserjrep ((real, real) , (real, real)) (real, real) 
box = point (XI, Yl) <*> point (X2,Y2) <*> 

point (X3,Y3) <*> point (X4,Y4) » ( (XI , Yl) , (X3, Y3) ) 

<4= Y1==Y2, X1==X4, X2==X3,Y4==Y3, YKY4, XKX2 

point:: parserjrep (real, real) (real, real) 
point = terminal (X,Y) » (X,Y) 

The conditions assure that the points actually represent a box. Note that these 
constraints are settled before parsing the point. As a consequence, if the points 
do not have the shape of a box, the parser can fail as soon as possible. For 
instance, if the condition Y1==Y2 is not verified, the parser will fail just after 
parsing the second point. For our example to work properly, the language must 
be able to handle numerical constraints concerning still uninstantiated variables, 
and to check incrementally the accumulated constraints whenever new ones are 
imposed during the computation. Such an extension of the language considered 
so far is described in [1], and is actually implemented in the system TOy (with 
such this example is indeed executable). For example we can fix two points of 
the box and ask TOy for the conditions that the other two points must sat- 
isfy to form a box: box R [(1,2), (4,2), P, Q] == [] . The goal succeeds, 
and Toy returns the answer R == ((1, 2), (4, _A)) P == (4, _A) Q 
== (1 , _A) {_A>2 . 0 } which are the equations that the variables must sat- 

isfy, including an arithmetical constraint. 

6 Parsers as Data 

In previous sections the advantages of defining parsers in T Oy have been dis- 
cussed. Here we intend to show how functional- logic languages allowing higher- 
order patterns can consider parsers as , in a broader 

sense of the term than usual. It is worthwhile to point out that the following 
discussion is held in a purely declarative framework. 

6.1 The Structure of T Oy Parsers 

Consider the parser ab defined as: ab = terminal ’a’ <*> terminal ’b’ 

Function ab can reduce directly to its right-hand side (terminal ’a’ <*> 
terminal ’b’), while <*> and terminal need to be applied to the input 
sentence in order to reduce. Therefore we can say that the ’structure’ of ab 
has the shape A <*> B, where both A and B are of the form terminal T. The 
interesting point is that A <*> B and terminal T are valid HO patterns in 
Toy (see Sec. 2). In general, any parser P defined through the 
{<*> , <|>, » , empty, satisfy, terminal}, can be decomposed by matching 
it with suitable HO patterns. In this context, the basic components can be 
effectively considered as , and parsers as 
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6.2 Folding Parsers 

Functions are widely used in FP. They replace the constructors of data 
structures by given functions. The most usual examples of these constructions 
are those that handle lists, i.e. the standard functions f oldr, f oldl, . . . , but the 
same technique can be applied to other structures (see [18] for many examples). 
As we have shown above, parsers can be considered data values, and hence we can 
define a function foldp that replaces the constructors of a parser by arbitrary 
functions. The definition is a little bit tedious, but straightforward: 

foldp (Emp, empty = Emp 

foldp (_, Ter (terminal T) = Ter T 
foldp Sat, (satisfy P R) = Sat P R 

foldp F@(_,_,_,Seq,_,_) ((<*>) A B) = Seq (foldp F A) (foldp F B) 

foldp F@(_, Alt, _) ((<[>) A B) =Alt (foldp F A) (foldp F B) 

foldp F@(_, Rep) (( ») A B R) = Rep (foldp F A) B R 

The first argument of foldp is a tuple of the form (Emp, Ter, Sat, Seq, Alt, 

Rep) with the functions that will replace the ‘constructors’ empty, terminal, 
satisfy, <*> , <|> and » respectively. The second argument is the parser 
we want to ‘fold’. Function foldp is recursively applied, replacing each con- 
structor by its correspondent function. At first sight, function foldp might seem 
useless. Indeed, most of the parser definitions are recursive, and hence their basic 
structures are infinite: function foldp would peer into such structures forever, 
if normal forms were being looked for. Instead we will show that, due to lazy 
evaluation, function foldp allows us to check interesting properties of the repre- 
sented grammar, such as ambiguity. Observe that (apart from syntactic details) 
the definition of foldp is by no means a valid program, due to the 

presence of HO patterns. 



6.3 Checking Ambiguity 

We say that a grammar specification is ambiguous when a sentence exists with 
more than one parse tree. Consider for instance the grammar represented by the 
following Toy parser (we have labelled the productions with PI, P2 and P3): 

s = terminal ’i’ <*> s <*> terminal ’e’ <*> s (PI) 

<|> terminal ’i’ <*> s (P2) 

<|> terminal ’o’ (P3) 

This grammar is ambiguous, since the sentence . . can be derived following 
either the left derivation or . As ambiguity is not 

a nice property when defining grammars for programming languages, we would 
like to define a function that look for ambiguous words. A possible solution is to 
define a parser with representation s ’ , whose representation is the parse tree. By 
using s ’ we can look for sentences with two different representations. However 
this means that we need to define a parser P ’ each time we want to study the 
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ambiguity of a parser . Obviously, it is much better to mechanize this process 
by defining a suitable function build_tree that converts a given parser into 
a new parser that returns as representation parse trees. This function can be 
defined in terms of foldp as follows: 

build_tree : : parser A ^ parserjrep [int] A 

build_tree = foldp (empty_t,term_t,sat_t,seq_t,alt_t,rep_t) 

where 



empty_t 


= empty 


» 


[] 


term_t T 


= terminal T 


» 


[] 


sat_t P RI 


= satisfy P RI 


» 


[] 


seq_t PI P2 


= PI RI <*> P2 R2 


» 


R1++R2 


alt_t PI P2 


= PI R 


» 


[1|R] 




<|> P2 R 


» 


[2|R] 


rep_t P Expr Rep 


= (P Tree » Expr) Rep 


» 


Tree 



To represent the parse tree we use a list which collects the chosen alternatives 
as a sequence of I’s (first alternative) and 2’s (second alternative). In the case 
of empty, terminal and satisfy the sequence of alternatives is the empty list. 
In order to understand the sequence and the alternative we must keep in mind 
that PI and P2 have been ‘folded’ already. The sequence applies each parser and 
concatenates the two resulting lists, while the alternative includes the number 
of the chosen option in the current representation. Finally, rep_t takes charge 
of the parsers with representation. It first applies the parser, getting the list 
of alternatives. Then the parser is again converted into a parser with represen- 
tation, in order to keep the initial representation unaffected. For instance, the 
goal build_tree s L "iioeo" == [] succeeds with R == [1, 2, 1, 2, 2, 
2 , 2 ] as well as with R== [2, 1, 1, 2, 2, 2, 2]. Owing to the right 
associativity of <|>, the sequence 1 means that that the production (PI) was 
applied, while 2,1 stands for (P2) and 2,2 stands for production (P3). 

Now it is easy to define a function that looks for words with two different 
parse trees: 

ambi : : parser A ^ [A] 

ambi P = W <1= gen_word==W, build_tree P R1 W == [], 

build_tree P R2 W == [] , not (R1 == R2) 

The first condition is used to generate general words in a non-deterministic 
fashion (see below). The next two conditions try to parse the word twice, while 
the third condition assures that the two representations returned are different. If 
they are equal, then backtracking is enforced and a new parse is tried. Otherwise 
the word W admits two different parse trees (i.e. the grammar is ambiguous) and 
W is returned. Observe that we are using here the LP capabilities of our language, 
since R1 and R2 are new (existential) variables. It is also worth noticing that both 
the fold and the parsing of the input sentence are performed at the same time, 
avoiding the folding of unsuccessful (and infinite) branches of the parse tree. 
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Since ambiguity is a semidecidable property, we should only check words in 
a given range of length. If we find that the parser is ambiguous for any of these 
words, we have demonstrated that it is ambiguous. Otherwise, we can either try 
a wider range of lengths, or accept this partial result of non-ambiguity. Owing 
to this we define a non-deterministic function word_from_to which generates all 
the general sentences, i.e. lists of variables, whose length is less than or equal to 
a given number N. 

all_words N = [ ] 

all_words N= [_|all_words (N-1)] N > 0 
Thus we can define gen_words, for instance, as: gen_words = all_words 10. At 
this point we can check that s is ambiguous by trying the goal ambi s == W 
which succeeds with W == "iioeo". Conversely, similar goals for the parsers with 
representation expression and p, both defined in Sect. 5, will fail, meaning that 
there is no expression or palindrome word whose length is less than or equal to 
10 with two different parse trees. 

7 Conclusions 

This paper shows how a functional-logic language supporting non-deterministic 
functions allows defining parsers which combine most of the nicest properties of 
both functional and logic parsers. Our approach has been presented by means 
of a concrete language, TOy, but other functional- logic languages supporting 
non-deterministic functions like Curry [11] could have been used. Specifically, 
the expressiveness of T Oy parsers is akin to that of FP parsers, but based on 
simpler concepts and definitions. This is due to the adoption in our model of 
typical LP characteristics, like the natural way of handling non-determinism pro- 
vided by non-deterministic computations. Also, parsing in TOy benefits from 
the use of logical variables to return representations, thus avoiding the intro- 
duction of monads and lambda abstractions. Actually, this technique can be 
generalized, and represents a simple and natural FTP alternative to monads in 
many situations (see [5]). Despite their ’functional’ shape, parsers in TOy share 
with parsers of LP the possibility of multiple modes of use, generating as well 
as recognizing sentences. We have also investigated further possibilities of our 
approach to parsers, making use in this case of more specific features of TOy. 
First, we have briefly indicated how these parsers benefit from the inclusion of 
arithmetical constraints. In a different direction, TOy's possibility of using HO 
patterns in heads of rules has given parsers the role of data values in a very 
strong sense. We have defined a function for them, and used this function 
to check the ambiguity of grammars. Other interesting properties of the under- 
lying grammars, such as the LL{1) property, can be also checked using the same 
technique, as shown in [4]. 
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Abstract. A distinguishing feature of logic and functional logic lan- 
guages is their ability to perform computations with partial data and 
to search for solutions of a goal. Having a built-in search strategy is 
convenient but not always sufficient. For many practical applications 
the built-in search strategy (usually depth-first search via global back- 
tracking) is not well suited. Also the non-deterministic instantiation of 
unbound logic variables conflicts with the monadic I/O concept, which 
requires a single-threaded use of the world. 

A solution to these problems is to encapsulate search via a primitive 
operator try, which returns all possible solutions to a search goal in a 
list. In the present paper we develop an abstract machine that aims at 
an efficient implementation of encapsulated search in a lazy functional 
logic language. 



1 Introduction 

A distinguishing feature of logic and functional logic languages is their abil- 
ity to perform computations with partial data and to search for solutions of a 
goal. Having a built-in search strategy to explore all possible alternatives of a 
non-deterministic computation is convenient but not always sufficient. In many 
cases the default strategy, which is usually a depth-first traversal using global 
backtracking, is not well suited to the problem domain. In addition, global non- 
determinism is incompatible with the monadic I/O concept [PW93]. In this 
concept the outside world is encapsulated in an abstract data type and actions 
are provided to change the state of the world. These actions ensure that the 
world is used in a single-threaded way. Global non-determinism would defeat this 
single-threaded interaction with the world. Encapsulated search [SSW94,HS98] 
provides a remedy to both of these problems. 

In this paper we develop an abstract machine for the functional logic lan- 
guage Curry [Han99]. Curry is a multi-paradigm language that integrates fea- 
tures from functional languages, logic languages and concurrent programming. 
Curry uses lazy evaluation of expressions and supports the two most important 
operational principles developed in the area of functional logic programming, 
narrowing and residuation. Narrowing [Red85] combines unification and reduc- 
tion. With narrowing unbound logic variables in expressions may be instantiated 
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non-deterministically. With the residuation strategy [ALN87], on the other hand, 
the evaluation of expressions containing unbound logic variables may be delayed 
until these variables are sufficiently instantiated by other parts of the program. 
Unfortunately this strategy is known to be incomplete [Han92]. 

Our abstract machine is a stack-based graph reduction machine similar to the 
G-machine [Joh84] and the Babel abstract machine [KLMR92]. Its novel feature 
is the implementation of encapsulated search in an efficient manner that is com- 
patible with the overall lazy evaluation strategy of Curry. Due to the lack of space 
we restrict the presentation of the abstract machine to the implementation of the 
encapsulated search. The full semantics of the machine can be found in [LK99]. 
In the rest of the paper we will assume some familiarity with graph reduction 
machines for functional and functional logic languages [,loli84,KLMR92]. 

The rest of this paper is organized as follows. In the next section the computa- 
tion model of Curry is briefly reviewed and the search operator try is introduced. 
The third section introduces the abstract machine. In section 4 an example is 
presented, which demonstrates the operation of the abstract machine. The sixth 
section presents some runtime results for our prototypical implementation. The 
last two sections present related work and conclude. 

2 The Computation Model of Curry 

Curry uses a syntax that is similar to Haskell [HPW92], but with a few additions. 

The basic computational domain of Curry is a set of data terms. A data 
term t is either a variable x or constructed from an n-ary data constructor c, 
which is applied to n argument terms: 

t X \ c ti ... tn 

New data constructors can be introduced through data type declarations, e.g. 
data Nat = Zero I Succ Nat. This declaration defines the nullary data con- 
structor Zero and the unary data constructor Succ. 

An expression e is either a variable x, a data constructor c, a defined function 
/, or the application of an expression ci to an argument expression 62 : 

e ::= a: I c I / I ei 62 

Curry provides a predefined type Constraint. Expressions of this type are 
checked for satisfiability. The predefined nullary function success reduces to a 
constraint that is always satisfied. An equational constraint ei =:=62 is satisfied, 
if 6 i and 62 can be reduced to the same (finite) data term. If e\ or 62 contain 
unbound logic variables, an attempt will be made to unify both terms by instan- 
tiating variables to terms. If the unification succeeds, the constraint is satisfied. 
E.g the constraint Succ m=:=Succ Zero can be solved by binding m to Zero, if 
m is an unbound variable. 

Functions are defined by conditional equations of the form 



f ti ... tn \ g = e 
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where the so-called guard 5 is a constraint. A conditional equation for the func- 
tion / is applicable in an expression / ei ... en, if the arguments ei, ... , 6 n 
match the patterns ti,. . . ,tn and if the guard is satisfied. The guard may be 
omitted, in which case the equation is always applicable if the arguments match. 

A where clause can be added to the right hand side of an equation to provide 
additional local definitions, whose scope is the guard g and the expression e. Un- 
bound logic variables can be introduced by the special syntax^ where xi, . . . ,Xn 
free 

A Curry program is a set of data type declarations and function definitions. 
The following example defines a predicate and an addition function for natural 
numbers. 

nat Zero = success add Zero n = n 

nat (Succ n) = nat n add (Succ m) n = add m (Succ n) 

2.1 Reduction Strategy 

An / is a pair of an expression e and a substitution a that de- 

scribes the bindings for the free variables of the expression e. An answer expres- 
sion is written as a [] e. The computational domain is a set of answer expressions. 
E.g. the solution of the goal f x where x is a free variable and the function f is 
defined by 

f 0 = 1 
f 1 = 2 

is the set 

{{xh^0 }[]l,{xH^ 1 }[]2 } 

A single computation step performs a reduction of exactly one unsolved ex- 
pression in the set and returns a set of answer expressions for it. If this set has 
exactly one element, the computation step was deterministic. Otherwise the the 
computation either failed and the set is empty or a non-deterministic computa- 
tion step was performed. 

An attempt to reduce an expression / ei . . . e„ triggers the evaluation of 
ei, . . . , e„ according to a left-to-right pattern-matching strategy. Thus, in order 
to reduce the expression nat (add Zero Zero), the argument (add Zero Zero) 
is reduced to head normal form (i.e., a term without a defined function symbol 
at the top) in order to select an applicable equation of the function nat. 

If an argument is an unbound variable, as e.g. in nat n, the further com- 
putations depend on the evaluation mechanism to be used. When narrowing is 
used, a non-deterministic computation step is performed that yields a set which 
contains an answer expression for each possible binding of the variable. In the 
example, the reduction would yield the set 

{{n H- > Zero} [] success, {n 1— s- Succ m} [] nat m} 

The same syntax is also applicable to let expressions. 
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where m is a fresh, unbound variable. If residuation is used, the evaluation is de- 
layed until the variable has been instantiated by some other concurrent compu- 
tation. By default, constraint functions use narrowing as their evaluation mech- 
anism, while all other functions use residuation. The user can override these 
defaults by evaluation annotations. 

The concurrent evaluation of subexpressions is introduced by the concurrent 
conjunction ci & C 2 of two constraints, which evaluates the constraints ci and 
C 2 concurrently and is satisfied iff both are satisfiable. For example we might 
implement the subtraction on natural numbers with two concurrent computa- 
tions. The second acts as generator of natural numbers, while the first checks if 
a generated number added to second argument of the subtraction yields the first 
argument of the subtraction: 

sub m n I add s n=:=m & nat s = s where s free 
2.2 Encapsulated Search 

The use of monadic I/O, which assumes a single-threaded interaction with the 
world, conflicts with the non-determinism stemming from the instantiation of 
unbound variables. For that reason Curry provides the primitive search opera- 
tor try : : (a->Constraint) -> [a->Constraint] that allows to confine the 
effects of non-determinism. This operator can also be used to implement find-all 
predicates in the style of Prolog, but with the possibility to use other strategies 
than the built-in depth first search [HS98]. 

The argument of try is the . . y . The argument of the search goal can 

be used to constrain a goal variable by the solutions of the goal. The result of 
try is either an empty list, denoting that the reduction of the goal has failed, 
or it is a singleton list containing a function \x -> g, where g is a satisfiable 
constraint (in solved form), or the result is a list with at least two elements 
if the goal can be reduced only by a non-deterministic computation step. The 
elements of this list are search goals that represent the different alternatives for 
the reduction of the goal immediately after this non-deterministic step. 

For instance, the reduction of 

try (\x -> let s free in add s x=:=Succ Zero & nat s) 
yields the list 

[\x -> add Zero x=:=Succ Zero & success, 

\x -> let t free in add (Succ t) x=:=Succ Zero & nat t] 

3 The Abstract Machine 

3.1 Overview 

The abstract machine developed in this paper is a stack based graph reduction 
machine, that implements a lazy evaluation strategy. The concurrent evaluation 
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of expressions is implemented by assigning each concurrent expression to a new 
thread. The main contribution of the machine is its lazy implementation of 
encapsulated search, which is described in more detail below. 

The state space of the abstract machine is shown in Fig. 1. The state of the 
abstract machine is described by an 8-tuple (c, ds, es, hp, H, rq, scs, tr), where c 
denotes a pointer to the instruction sequence to be executed. The data stack ds 
is used to supply the arguments during the construction of data terms and func- 
tion applications. The environment stack es maintains the environment frames 
(activation records) for each function call. An environment frame comprises a 
size field, the return address, where execution continues after the function has 
been evaluated, the arguments passed to the function, and additional free space 
for the local variables of the function. 



State £ Instr* x Adr* x Env Frame* x Adr * xHeap x ThdState* 

X SearchContext* x Trail 
Instr — {PushArg, Pushint, . . .} 

Adr = IN 

Heap = Adr > Node 

Node = {Int} x I'l U {Data} x I'l x Adr* U {Clos} x Instr* x IN x IN x Adr* 
U {SrchContO} X ThdState x ThdState* x SearchSpace 
U {SrchContl} X ThdState x ThdState* x SearchSpace x (Adr U ?) 

U {Susp} X Adr U {Lock} x ThdState* U {Var} x ThdState* 

U {Indir} X Adr 

EnvFrame = IN x Instr* x (Adr U ?)* 

ThdState = Instr* x Adr* x EnvFrame* 

SearchContext Adr x Instr* x Adr* x EnvFrame* x ThdState* x Trail 
SearchSpace = Adr x Trail x Trail 
Trail — {Adr x Node)* 



Fig. 1. State space 



The graph corresponding to the expression that is evaluated, is allocated in 
the heap H . The register hp serves as an allocation pointer into the heap. We 
use the notation H[a/n] to denote a variant of the heap H which contains the 
node n at address a. 



H[a/x\{a') 



X ii a = a' 
H{a') otherwise 



The graph is composed of tagged nodes. Integer (int) nodes represent integer 
numbers. Data nodes are used for data terms and comprise a tag, which enumer- 
ates the data constructors of each algebraic data type, and a list of arguments. 
The arity of a data constructor is fixed and always known to the compiler, for 
that reason it isn’t recorded in the node. 
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Closure (Clos) nodes represent functions and function applications. Besides 
the code pointer they contain the arity of the function, the number of additional 
local variables, and the arguments that have been supplied. The closures returned 
from the encapsulated search are represented by two kinds of search continuation 
nodes (SrchContO and SrchContl), which will be described in more detail in the 
next section. 

Unbound logic variables are represented by variable (Var) nodes. The wait 
queue field of these nodes is used to collect those threads, that have been sus- 
pended due to an access to the unbound variable. 

Suspend (Susp) nodes are used for the implementation of lazy evaluation. 
The argument of a suspend node points to the closure or search continuation, 
whose evaluation has been delayed. Once the evaluation of the function applica- 
tion begins, the node is overwritten by a Lock node, in order to prevent other 
threads from trying to evaluate the suspended application. Those threads will 
be collected in the wait queue of the lock. If the evaluation of the function ap- 
plication succeeds the node is overwritten again, this time with an indirection 
(indir) node, that points to the result of the application. Indirection nodes are 
also used when a logic variable is bound. The variable node is overwritten in 
that case, too. 

The run queue rq maintains the state of those threads, which are runnable, 
but not active. For each thread the instruction pointer and the thread’s data 
and environment stacks are saved. The search context stack scs is used to save 
the state of the abstract machine when an encapsulated search is invoked. In 
each search context the pointer to the instruction, where execution continues 
after the encapsulated search returns, the data and environment stacks, the run 
queue, and the trail are saved. In addition the address of the goal variable is 
saved in a search context. 

The final register, tr, holds a pointer to the trail, which is used to save the 
old values of nodes that have been overwritten, so that they can be restored 
upon backtracking or when an encapsulated search is left. 

The instruction set of the abstract machine is shown in Fig. 2. Many of these 
instructions operate similarly to the G-machine [.Ioli87] and the Babel abstract 
machine [KLMR96]. They are not described in this paper due to lack of space. 

3.2 Encapsulated Search 

Representation of search goals A search goal that is reduced by the en- 
capsulated search, is a unary function of result type Constraint. The encapsu- 
lated search returns if the goal either fails, succeeds or can only proceed non- 
deterministically. The result is a list of closures, where each closure is of the form 
x->xi= : =ei& . . . : =e„&c. Here xi , . . . , denote the logic variables that have 

already been bound to some value (the parameter x can be a member of this 
list) and c represents the yet unsolved part of the search goal. This form is not 
suitable to be used in the abstract machine, however, because we cannot change 
the code of the search goal dynamically. A more suitable representation is de- 
rived from the fact, that the closure represents the continuation of the search 
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PushArg n 


SwitchOnTerm tags&labels 


TryMeElse label 


Pushint % 


Jmp label 


RetryMeElse label 


PushGlobal n 


Jmp Cond label 


TrustMe 


PushVar 


BindVar 


Fail 


Pop n 


Eval 


Succeed 


PackData tag, n 


Return 


Solve 


SplitData m, n 


Fork label 




SaveLocal n 


Delay 




Apply n 


Yield 




Suspend n 


Stop 






Fig. 2. Instruction set 





goal at the point, where the non-deterministic computation step takes place. 
Such a continuation is described by the current contents of the machine reg- 
isters together with the bindings for the logic variables. A search continuation 
(SrchContl) node is used to represent this kind of continuation (see Fig. 1). 



Local search spaces The different solutions of the search goal may use different 
bindings for the logic variables and suspended applications contained in the 
search goal. For instance, in the example given earlier, the local variable s is 
bound to the constant Zero in the first alternative and to the data term Succ t 
in the second one. 

For efficiency reasons, we do not want to copy the graph corresponding to the 
search goal for every solution. Instead we share the graph among all solutions 
and use destructive updates to change the bindings whenever a different search 
continuation is invoked. Therefore every search continuation is associated with a 
search space, that contains the list of addresses and values that must be restored, 
when the search continuation is invoked (the . ... of the search space), and 

those which must be restored, when the encapsulated search returns (the . . 
of the search space). In addition the search space also contains the address of 
the logic variable, that was used as an argument to the search goal in order to 
start its evaluation. 



Invocation of search goals A new encapsulated search is started by the Solve 
instruction. This instruction will save the current machine state in a search 
context on the search context stack scs. If the argument passed to Solve is a 
closure node, i.e. the search goal is called for the first time, a fresh, unbound 
variable is allocated and the search goal is applied to it. 

(Solve : c, dsi : ds, es, hp, H, rq, scs, tr) 

(c', hp : e, e, hp + 1, H[hp/ (Var, e)], e, {hp, c, ds, es, rq, tr) : scs, e) 
where H[dsi] = (Clos, c", ar,l,a\, . . . , Oar-i) 
and d = Apply 1 : Suspend : Eval : Succeed : e 
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If instead the argument to the Solve instruction is a search continuation, the 
bindings from its search space have to be restored before the execution of the 
goal can continue. No new goal variable needs to be allocated in this case. 

(Solve : c, dsi : ds, es, hp, H, rq, scs, tr) 

(c', ds' , es', hp, restore{H, scr), (g, c, ds, es, rq, tr) : scs, tr') 
where H[dsi] = (SrchContl, (c', ds' , es'),rq' , {g, scr, tr')) 



The auxiliary function restore is defined as follows: 



restore{H,tr) := 



H if tr = e 

restore{H[a/x],tr') if tr = (a,x) : tr' 



Returning from the encapsulated search There are three different cases 
to consider here. The easy case is when the search goal fails. In that case, the 
old heap contents and the top-most context from the search context stack are 
restored and an empty list is returned into that context. 

(Fail : c, ds, es, hp, H, rq, {g, c', ds' , es', rq' , tr') : scs, tr) 

(c', hp : ds' , es' , hp + 1, restore{H, tr)[hp! (Data, [] )], rg', scs, tr') 



If the search goal succeeds, a singleton list containing the solved search goal 
must be returned to the context, which invoked the encapsulated search. This 
is handled by the Succeed instruction, that detects this special case from the 
presence of an empty return context. 

(Succeed : c, ds, e, hp, H, e, {g, c' , ds' , es' , rq' , tr') : scs, tr) 

(c', hp : ds' , es' , hp + 3, H", rq' , scs, tr') 
where spc = {g, save{H, tr),tr) 

H' = restore{H, tr) 

H" = H'[ /ip/(Data, :,hp+ l,hp+2), 

hp + l/(SrchContl, (Succeed : c, e, e), e, spc, ?), 
hp + 2/(Data, [])] 



The save function saves the bindings of all variables that have been updated 
destructively. These are those nodes, which have been recorded on the trail: 



save{H, tr) 



e if tr = e 

{a,H[a\) : save{H,tr') if tr = {a,n) : tr' 



In case of a non-deterministic computation step, a list must be returned 
as well. However, in this case the tail of that list is not empty. Instead it will 
contain the search continuations for the remaining alternatives. Due to the lazy 
evaluation semantics of Curry, this tail has to be a suspended application. We 
use a second kind of search continuation node (SrchContO) for that purpose. 
These search continuations do not accept an argument, as they just jump to the 
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alternative continuation address encoded in the TryMeElse and RetryMeElse 
instructions. 

(TryMeElse alt : c, ds, es, hp, H, rq, {g, c' , ds' , es' , rq' , tr') : scs, tr) 

(c', hp : ds' , es' , hp + 3, H" , rq' , scs, tr') 
where spc = {g, save{H, tr),tr) 

H' = restore{H, tr) 

H" = H'[ hp/ (Data, ( : , hp + 1, hp + 2)), 

hp + l/(SrchContl, (c, ds, es), rg, spc, ?), 
hp + 2/ (SrchContO, {alt, ds, es),rq, spc)] 

The RetryMeElse and TrustMe instructions are handled similarly. 

Unpacking the result In order to access the computed solution for a search 
goal, the (solved) search goal must be applied to an unbound logic variable. 
This variable will then be unified with the corresponding binding computed in 
the search goal (if any) . The unpack function 

unpack g I g x = x where x free 

can be used for that purpose. 

In the abstract machine, the Eval instruction therefore must also handle 
suspended applications of search continuations. In that case, the saved search 
space is merged into the current search space and then execution continues in the 
solved goal. This will immediately execute the Succeed instruction, which unifies 
the value, that was bound to the goal variable, with the argument applied to the 
search continuation and then returns into the context where Eval was invoked.^ 

(Eval : c,ds\ : ds,es,hp, H[dsi/{SvLsp,a)],rq, scs,tr) => 

(c', ds' ++ ds', (2 : c : a : g') : es' ,hp + 1,H' , rq' ++ rq, scs, tr' ++ tr) 
where H[a] = (SrchContl, (c', ds', es'),rq' , {g, scr, tr'),a') 

H' = restore{H, scr) [hp/ (Locked, e)j 
(Succeed : c, ds, es, hp, H, rq, scs, tr) 

{c', ds, es, hp, H, rq, scs, tr) 

where c' = PushArg 1 : PushArg 0 : BindVar : Return : e 
and es yf e 

4 An Example 

In order to demonstrate the operation of the abstract machine, we will consider 
the function 

sub m n I add s m=:=n & nat s = s where s free 

again. The code for this function, together with the code for the functions nat 
and add introduced earlier, and the code for the primitive function & are shown 
in Fig. 3. 

^ For the purpose of the presentation, we assume that the search goal is always applied 
to an unbound variable, so that the BindVar instruction is applicable. The machine 
in fact allows other arguments to be applied as well. 
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Fn "sub" sub 2 1 
sub : PushVar 

SaveLocal 2 
PushArg 2 
PushGlobal "nat" 
Apply 
Suspend 
PushArg 0 
PushArg 1 
PushArg 2 
PushGlobal "add" 
Apply 2 
Suspend 

PushGlobal "=:=" 

Apply 2 

Suspend 

PushGlobal "&" 

Apply 

Suspend 

Eval 

Pop 1 

PushArg 2 

Return 



Fn 120 
Fork 1.1 
PushArg 1 
Eval 
Pop 1 
PushArg 0 
Eval 
Return 

1.1: PushArg 0 
Eval 
Stop 



Fn "add" add 2 1 
add: PushArg 0 

add.l: SwitchOnTerm [<Susp> : add. 2 , <Var> : add. 3, 
Zero : add. 4, Succ : add. 5] 

add . 2 : Eval 

Jump add . 1 
add. 3: Delay 

Jump add . 1 
add . 4 : Pop 1 

PushArg 1 
Return 

add. 5: SplitData 2 1 
PushArg 1 
PackData Succ 1 
PushArg 2 
PushGlobal "add" 

Exec 2 



Fn "nat" nat 1 1 

nat : PushArg 0 

nat . 1 : SwitchOnTerm [<Susp> :nat . 2 , <Var> :nat . 3, 
Zero : nat . 4 , Succ : nat . 6] 

nat . 2 : Eval 

Jump nat . 1 

nat. 3: TryMeElse nat . 5 
PushAtom Zero 
BindVar 

nat . 4 : Pop 1 

PushGlobal "success" 

Exec 0 

nat . 5 : TrustMe 

PushVariables 1 
PackData Succ 1 
BindVar 

nat. 6: SplitData 1 1 
PushArg 1 
PushGlobal "nat" 

Exec 2 



Fig. 3. Sample code 
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The code for the function sub constructs a suspended application for the 
guard expression add s m=:=n & nat s. This application is then reduced to 
weak head normal form with the Eval instruction. If the evaluation of the guard 
succeeds, the result is discarded (it can only be the solved constraint) and the 
solution, which is the value bound to the logic variable s, is returned to the 
caller. 

The code for the primitive function &, which implements the concurrent con- 
junction of two constraints, creates a new thread using the Fork instruction as 
its first action. The new child thread, which becomes active immediately, shares 
the current environment frame with its parent, in order to access the arguments 
passed to the function. The child thread reduces the first argument of & to weak 
head normal form and then stops. The parent thread, once it becomes active 
again, reduces the second argument to weak head normal form and invokes Eval 
for the first argument, too. Because the evaluation of a suspended application 
replaces the Susp node by a Lock node, this will block the parent thread until 
the child thread has completed the evaluation of the first argument. 

The function add dispatches on the kind of its first argument with the help 
of the SwitchOnTerm instruction. If the argument is a suspend node, it will 
be reduced to weak head normal form with the Eval instruction. Otherwise, if 
the node is an unbound variable, the Delay instruction will suspend the current 
thread until that variable is instantiated. In both cases the code then redispatches 
on the result of the evaluation or the instantiated variable, resp. If the node is 
neither a suspend node nor an unbound variable, then it must be already in 
weak head normal form and the code jumps directly to the compiled code of the 
corresponding equation. 

The function nat similarly dispatches on the kind of its argument. If the 
argument is a suspend node it will be evaluated and otherwise, if it is not an 
unbound variable, the abstract machine will jump directly to the code for the 
matching equation. If the argument is an unbound variable, the function has 
to instantiate that variable non-deterministically. This is implemented with the 
help of the TryMeElse and TrustMe instructions in this example. When the 
TryMeElse instruction is executed, the abstract machine saves the current ma- 
chine state into two search continuation nodes. The first of them is a SrchContl 
node whose instruction pointer contains the address of the instruction following 
the TryMeElse instruction, i.e. in our example the instruction PushAtom Zero. 
The second search continuation is a SrchContO node, that shares the machine 
state with the former search continuation but has a different continuation ad- 
dress. Its instruction pointer contains the address of the instruction at the label 
of the TryMeElse instruction, i.e. in our example the TrustMe instruction. Both 
search continuations are packed into a list node and the abstract machine re- 
turns to the top-most context on the search context stack with the the list node 
on the top of the data stack. The RetryMeElse and TrustMe instructions work 
similarly, except that for TrustMe the tail of the list node is an empty list instead 
of a search continuation. 
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When a SrchContl node is used as an argument to the try function, the 
saved machine state is restored and the execution continues at the addresss 
following the TryMeElse instruction. The correct local bindings for this search 
continuation are established with the help of the . . of the SrchContl node. 

Similarly the SrchContO node restores the saved state and continues at the 
TrustMe instruction. 



5 The Implementation 

We have implemented a prototype of our abstract machine. Our compiler trans- 
lates Curry source code into abstract machine code, which is then translated 
into native machine code using the well-known “C as portable assembler tech- 
nique” [HCS95,Pey92]. 

In our implementation we have integrated a few optimizations. Besides using 
unboxed representations for integer arithmetic like in the G-machine, we were 
particularly interested in implementing the encapsulated search efficiently. By 
using destructive updates, we have already minimized the cost for accessing vari- 
ables and applications. On the other hand we now have an additional overhead 
on entering and leaving the encapsulated search because the bindings of those 
nodes have to be updated. However, this update of bindings can be delayed un- 
til a search goal is called, that uses a different search space. Because (nearly) 
all updates affect nodes, that are local to the search space, there is no need to 
restore those bindings when the encapsulated space is left.^ If the search goal, 
that is invoked next, uses the same bindings, as will happen quite often in the 
case of a depth-first search strategy, then no actions need to be taken and the 
only overhead, that is caused by the use of the encapsulated search, is due to 
the creation of the search continuations. 

To test the efficiency of our abstract machine, we have run a few benchmarks 
on it. The results for three of these benchmarks are shown in Fig. 4. The first 
column lists the execution times for a functional version of the program, the 
second column shows the same benchmark, but using logical style. The third 
column shows the results for the benchmarks when translated into Prolog and 
compiled with Sicstus Prolog. The fourth column contains the execution times 
for the functional version of the benchmarks compiled with a state-of-the-art 
Haskell compiler (Glasgow Haskell). All times are given in seconds. 

The first benchmark tries to find a solution for the 8-puzzle using a best-first 
approach. The second benchmark computes the number of solutions for the 8- 
queens problems. The third benchmark shows the result for naive reverse with 
a list of 250 elements. The test is repeated 100 times. All benchmarks were run 
on an otherwise unloaded Ultra Sparc 1 equipped with 128 MBytes of RAM. 

® Any suspended applications that were used as additional arguments for the search 
goal have to be restored, however. These can easily be identified, if each suspend 
node is tagged with the search space, in which it was allocated. In practice such 
nodes seem to occur rarely. 
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Benchmark 


Functional 


Logic 


Sicstus 


ghc 


8-puzzle 


1.7 


4.1 


14.4 


0.13 


queens 


2.9 


6.5 


3.3 


0.92 


nrev 


13.7 


33.2 


22.7 


1.7 



Fig. 4. Runtime results 



From the figures one can see that our prototype compares well with a mature 
Prolog implementation. The functional version of the code is always slightly 
faster than the corresponding Prolog code, while the logical version is a little 
bit slower, except for the 8-puzzle. However, our implementation is still much 
slower than the code generated by the Glasgow Haskell compiler. 

6 Related Work 

The G-machine [.Joh87] implements graph reduction for a functional language. 
The Babel abstract machine [KLMR96] implements graph reduction for a func- 
tional language whose operational semantics is based on narrowing. It incorpo- 
rates ideas from the G-machine and the WAM [War83], which is the standard 
abstract machine for implementing Prolog. Our abstract machine extends this 
further by adding concurrent evaluation and encapsulated search. 

The encapsulated search in Gurry is a generalization of the search operator 
of Oz [Smo95]. Their abstract machine [MSS95] differs substantially from ours, 
because of the different computation model employed by Oz. In particular Oz 
uses eager evaluation instead of lazy evaluation and therefore lacks the possibility 
to compute only parts of a search tree. E.g. they could not handle a search goal 
like nats directly. 

The implementation of multiple binding environments has been studied in the 
context of OR-parallel implementations of logic programming languages [G.J93]. 

7 Conclusion 

In this paper we have developed an abstract machine designed for an efficient 
implementation of Gurry. The main contribution of the machine is the integration 
of encapsulated search into a functional logic language, that employs a lazy 
reduction strategy. One of the goals of the implementation was to minimize the 
overhead, that stems from the use of encapsulated search. The prototype, that 
we have implemented, works reasonably fast compared with the same programs 
compiled in Prolog. However, we are still at least a magnitude slower than a 
current state-of-the-art compiler for a functional language. This is due to the 
fact, that our present compiler does not perform any sensible analysis on the 
source code. We are currently developing dedicated optimizations in order to 
include them into the Gurry compiler. 



Implementing Encapsulated Search for a Lazy Functional Logic Language 113 



References 



ALN87. 


H. Ait-Kaci, P. Lincoln, and R. Nasr. Le Fun: Logic, Equations, and Func- 
tions. Proc. ILPS’87, pp. 17-23, 1987. 101 


GJ93. 


G. Gupta and B. Jayaraman. Analysis of Or-Parallel Execution Models. 
ACM TOPLAS, 15(4):659-680, Sept. 1993. 112 


Han92. 


M. Hanus. On the Completeness of Residuation. Proc. JICSLP’92, pp. 
192-206. MIT Press, 1992. 101 


Han99. 


M. Hanus. Curry: An integrated functional logic language, (version 0.5). 
http://www-i2.informatik.rwth-aachen.de/~hanus/curry, 1999. 100 


HCS95. 


F. Henderson, Th. Conway, and Z. Somogyi. Compiling Logic Programs 
to C Using GNU C as a Portable Assembler. Proc. of the ILPS ’95 Post- 
conference Workshop on Sequential Implementation Technologies for Logic 
Programming Languages, pp. 1-15, 1995. Ill 


HPW92. 


P. Hudak, S. Peyton Jones, and P. Wadler. Report on the Programming 
Language Haskell (version 1.2). SIGPLAN Notices, 27(5), 1992. 101 


HS98. 


M. Hanus and F. Steiner. Controlling Search in Declarative Programs. Proc. 
PLILP’98, pp. 374-390, 1998. 100, 103 


Joh84. 


T. Johnsson. Efficient Compilation of Lazy Evaluation. Proc. SIGPLAN’84 
Symposium on Compiler Construction, pp. 58-69, 1984. 101, 101 


Joh87. 


T. Johnsson. Compiling Lazy Functional Languages. PhD thesis, Chalmers 
Univ. of Technology, 1987. 105, 112 


KLMR92. 


H. Kuchen, R. Loogen, J. Moreno-Navarro, and M. Rodriguez-Artalejo. 
Graph-Based Implementation of a Functional Logic Language. Proc. ALP 
1990, pp. 298-317. Springer LNCS 463, 1992. 101, 101 


KLMR96. 


H. Kuchen, R. Loogen, J. Moreno-Navarro, and M. Rodriguez-Artalejo. 
The Functional Logic Language Babel and its Implementation on a Graph 
Machine. New Generation Computing, 14:391-427, 1996. 105, 112 


LK99. 


W. Lux and H. Kuchen. An Abstract Machine for Curry. Technical Report, 
Univerisity of Munster, 1999. 101 


MSS95. 


M. Mehl, R. Scheidhauer, and Ch. Schulte. An Abstract Machine for Oz. 
Proc. PLILP’95, pp. 151-168. Springer, LNCS 982, 1995. 112 


Pey92. 


S. Peyton Jones. Implementing Lazy Functional Languages on Stock Hard- 
ware: The Spineless Tagless G-machine. Journal of Functional Program- 
ming, 2(l):73-80, Jan 1992. Ill 


PW93. 


S. Peyton Jones and P. Wadler. Imperative Functional Programming. Proc. 
20th POPL’93, pp. 123-137, 1993. 100 


Red85. 


U. Reddy. Narrowing as the Operational Semantics of Functional Lan- 


Smo95. 


guages. Proc. ILPS’85, pp. 138-151, 1985. 100 

G. Smolka. The Oz Programming Model. In J. van Leeuwen (ed.). Current 
Trends in Computer Science. Springer LNCS 1000, 1995. 112 


SSW94. 


Ch. Schulte, G. Smolka, and J. Wiirtz. Encapsulated Search and Constraint 
Programming in Oz. Proc. of the Second Workshop on Principles and Prac- 
tice of Constraint Programming. Springer, 1994. 100 


War83. 


D. Warren. An Abstract Prolog Instruction Set. Technical Report 309, SRI, 
1983. 112 



Comparison of Deforestation Techniques for 
Functional Programs and for Tree Transducers 



Armin Kiihnemann 



Grundlagen der Programmiemng, 

Institut fur Softwaretechnik I, Fakultat Informatik, 
Technische Universitat Dresden, D-01062 Dresden, Germany, 
kuehneOorchid . inf . tu-dresden . de 



Abstract. We compare transformations for the elimination of interme- 
diate results in first-order functional programs. We choose the well known 
deforestation technique of Wadler and composition techniques from the 
theory of tree transducers, of which the implementation of functional 
programs yet does not take advantage. We identify syntactic classes of 
function definitions for which both techniques deliver equally efficient 
results and for which one technique is more powerful than the other. 
In particular, this paper offers a technique that eliminates intermediate 
results for certain kinds of function definitions, for which deforestation 
fails. 



1 Introduction 

Functional programs frequently use compositions of functions, where functions 
produce intermediate results, which are consumed by other functions. On the 
one hand this modular style of programming simplifies the design and the ver- 
ification of programs [13]. On the other hand the production and consumption 
of intermediate results can cause inefficiencies, in particular, if the intermediate 
results are structured objects like lists or trees. 

There are several techniques for transforming programs which use intermedi- 
ate results into programs which do not. We compare . , . _ [20,5], which 

is a well known optimization technique for functional programs, with some 

, from the theory of tree transducers [7]. The comparison is 

restricted to the twofold composition of first-order functions, which are defined 
by an extended scheme of primitive recursion, in which additionally simultaneous 
definitions of functions and nesting of terms in parameter positions are allowed. 
This scheme is called , . . . .. [3] (for short cf. also [2,4]). 

An mtt m translates trees over a ranked alphabet of input symbols into trees 
over a ranked alphabet of output symbols. For this translation process, m uses a 
ranked alphabet of functions which have at least rank 1, and a set of equations. 
Every function / is defined by a case analysis on the root symbol c of its first 
argument t. The right-hand side of the equation for / and c may contain recursive 
function calls, where the first argument of a function call is a variable that refers 
to a subtree of t. If every function of m has rank 1, then m is called . . / 
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. _ [17,19] (for short ). Throughout this paper we will use the 

following mtts ruapp, rrirev, mmir, and mex as examples, where iriex is a tdtt. 



mapp- pp {A xi) yi 
pp {B xi) yi 
PP N yi 

rrirev- ev {A xi) yi 
ev {B xi) yi 
ev N yi 



A{ pp xi yi) mmir- 
B ( ppxi yi) 
yi 



ir {A xi) yi 
ir {B xi) yi 
ir N yi 



A ( ir xi {A yi)) 
B ( ir xi {B yi)) 
yi 



ev xi {A yi) mex- 
ev xi {B yi) 

yi 



X {A xi) 
x {B xi) 
X N 



= B { X xi) 
= A{ X xi) 
= N 



The mtt mapp appends two lists containing list elements A and B, where lists 
are represented by monadic trees. In particular, the empty list is represented by 
the symbol N with rank 0. In analogy, mrev reverses a list I (starting with an 
application ev I N) by accumulating the list elements in the second argument 
of ev. The mtt mmir combines the features of mapp and mrev by appending a 
list I to a list which results from a reversal of I (by starting with an application 
ir I N). The mtt mex exchanges list elements Ahy B and vice versa. 

If we evaluate the expression e = ( x ( ir Iq 1 1 )), where Iq and h are lists, 
then ir produces an intermediate result. In particular, Iq is traversed .. 

. ir traverses Iq and x traverses Iq and Iq’s reversed image). Deforestation 
can be applied to e and to a program p, which consists of mex and (a slight 
syntactic variant of) mmir, and delivers an expression = ( irex Iq h) and a 
function 

irex {A x\) yi = B {. irex xi {A yi)) 

irex {B xi) yi = A (. irex xi {B yi)) 

irex N yi = x y\ 

For the evaluation of e^, the list Iq is traversed only ( irex traverses Iq 

and X traverses Iq's reversed image). 

In [4] it was shown that for the composition of an mtt with a tdtt (and vice 
versa) a single mtt can be constructed, which performs the same computation 
without producing an intermediate result. Since e represents a composition of the 
mtt mmir with the tdtt mex, we can get a new expression Cc = ( irex Iq { x 1 1 )) 
and a function 

irex {A xi) yi = B { irex x\ (B yi)) 

irex {B xi) yi = A {. irex x\ {A yi)) 

irex N yi = yi 

The evaluation of Cc requires only traversal of Iq. 

We will show that, like in our example, for the composition of an mtt m\ 
with a tdtt 7712 (in this order) deforestation successfully eliminates “intermediate 
symbols” which occur “outside” of the topmost function calls in right-hand sides 
of equations of ttii, but fails in eliminating symbols “inside” of these function 
calls. It turns out that the composition technique is more powerful, since it ad- 
ditionally eliminates the latter symbols. For compositions of tdtts with mtts (in 
this order), the transformation strategies of the composition technique and of de- 
forestation correspond to each other and thus deliver equally efficient programs. 
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Besides this introduction, the paper contains six further sections. In Section 2 
we fix elementary notions and notations. Section 3 introduces our functional lan- 
guage and mtts. Section 4 and Section 5 present deforestation and the composi- 
tion techniques, respectively. In Section 6 the techniques are compared. Finally, 
Section 7 contains further research topics. 

2 Preliminaries 

We denote the set of natural numbers including 0 by IN. For every m G IV, 
the set {!,..., m} is denoted by [m]. We will use the sets X = {xq, xi,X 2 , ■ ■ ■}, 
Y = {yo,yi,y 2 ,...}, Z = {zo,Zi,Z 2 ,...}, and V = X UY U Z of 

- . , . . - . , , - , - , , and , - . , respectively. For 

a string w and two lists wi, . . . , Wn and w[, . . . , of strings such that no pair Wi 

and Wj with i ^ j overlaps in w, we denote by w[wi/w [, . . . , Wn/w[.^] the string 
which is obtained from w by substituting every occurrence of Wi in ic by ru'. We 
abbreviate the , , _ _ [wi/w'i , . . . , w„/w[.^] by [wi/w'j^ \ Wi G {wi, . . . , w„}] 

or simply by [wi/w'j\, if the quantification is clear from the context. 

Let be a binary relation on a set K. Then, =^" and denote the n-fold 
composition and the transitive, reflexive closure, respectively, of =^. If k k' 
for k,k' G K and if there is no k” G K such that k' k” , then k' is called a 
, , k j... . . . =^, which is denoted by f{=^,k), if it exists 

and if it is unique. We abbreviate /(=^, k) by f{k), if is clear. 

A . ... is a pair {S, anks) where S' is a finite set and anks is a 

mapping which associates with every symbol s G S a natural number called the 
of the symbol. The set of elements of S with rank n is denoted by S*-"^. 
For a ranked alphabet S and a subset V' of V, the set of . S- . . 

- V', denoted by TglV'), is the smallest subset T C (SU W U {(, )})* such that 

- y' U S(°) C T and 

- for every s G S^”^ with n > 1 and ti, . . . ,t„ G T: (s ti . . .t„) G T. 

Ts{^) is abbreviated by T5. Let t G Ts(V'). The set of variables that occur in 
t is denoted by , ar(t) and the number of occurrences of symbols from a subset 
S' C S in t is denoted by \t\s' or simply by \t\, if A = S'. 

3 Functional Programs and Macro Tree Transducers 

We consider a simple first-order functional programming language P as source 
language for our transformations. Every program p G P consists of several mtts. 
For simplicity we choose a unique ranked alphabet C of constructor symbols, 
which is used to build up input trees and output trees of every mtt in p. This 
fact and the absence of initial functions differ from mtts in the literature. The 
functions of an mtt are defined by a case analysis on the first argument ( - 

y, .) via pattern matching, where only flat patterns are allowed. The other 
arguments are called . . y , , . . 
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Definition 1 Let C and F be ranked alphabets of . , . - , , (or 

. ) and ,, _ . . (or ,, - ), respectively, such that X, Y, 

C, and F are pairwise disjoint. We define the classes P, AC, D, and R of 

y - - - - and . y. . . . , respectively, by the 

following grammar. We assume that p, m, d, r, c, and / (also equipped with 
indices) range over the sets P, AC, D, R, C, and F, respectively. 

p ::= mi . . .mi (program) 

m di ... dh (macro tree transducer) 

d ::= f {ci x\ . . . Xk^) 2/i . • . y™ = (function definition) 



/ {Cq Xl . ..XkJ yi---yn = Tq 

r ■.■.= yi \ f XiTi . . .Tn \ cri . . .Tk (right-hand side) 

The sets of constructors and functions that occur in p G P are denoted by Cp 
and Fp, respectively. The set of functions that is defined in m G AC is denoted 
by Fm. In addition to the grammar, the following restrictions have to be fulfilled: 
For every i G [/] and / G Pm; , the mtt mi contains exactly one function definition 
for /. For every i,j G [1] with i yf j: P^. nPm,, = 0. For every i G [/], / G 
and c G there is exactly one equation of the form f (c x\ ... Xk) yi ... yn = 
hs{f,c), where hs{f,c)GTc^uF„.{{xi,...,Xk,yi,.-.,yn})- □ 

If Pm = Pm ^ for an mtt m, then m is a tdtt. The classes of tdtts and of mtts which 
are no tdtts are denoted by OP and by AC — TOP, respectively. A tree t is 
called - , if every variable occurs at most once in t. An mtt and a program, 

respectively, is called - . , if the right-hand side of each of its equations is linear. 

We add an index 1 (and I, respectively) to the class AC and its subclasses, 
if mtts with only one function (and linear mtts, respectively) are considered. 
Note that our classes are syntactic classes and no semantic classes (classes of 
computed functions), which are studied in the theory of tree transducers [7]. 

Example 2 m^x G OPi,z and mapp,mrev,mmir G {MAC — TOP )^ □ 

It turns out that deforestation in general translates a program p £ P into a 
program p' , in which in right-hand sides of an mtt m also applications of the 
form / ro Ti . . . r„ with / G (Pp' — Pm) and without restriction “rg = Xi for some 
xC can occur. We denote this target language by P+ and the set of constructors 
and functions that occur in p G P“*" by Cp and Pp, respectively. 

We fix call-by-name semantics, i.e. for every p G P~^ we use a call-by-name 
reduction relation =^>p on Tc^uFp- It can be proved that in contrast to general 
first-order programs, for every p G P and e G PcpUFp the normal form . f{^p, e) 
exists. The proof is based on the result in [4], that for every mtt the corresponding 
(nondeterministic) reduction relation is terminating (and confluent). 

In the framework of mtts, a function /i produces an intermediate result which 
is consumed by another function / 2 , iff an application of /i occurs in the . ar- 
gument of an application of / 2 . Thus, in this paper we would like to optimize the 
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evaluation of expressions of the form (/2 (/i to . . .tm) tni+i • ■ • tni+na)! where 
each ti is a tree over constructor symbols. Since the particular constructor trees 
are not relevant for the transformations, we abstract them by expression vari- 
ables and transform expressions of the form (/2 (/i zg . . . Zn-i+i ■ ■ ■ 
which we call . . _ . . . The transformations will deliver expres- 

sions of the form (/ Zq zi . . . z„) or (/ zq (/i zi) . . . (/„ z„)). All these expressions 
are special initial expressions for programs, which are defined as follows. 

Definition 3 Let p € and let / range over Fp. The set of . 

, p, denoted by Ep, is defined as follows, where e (also equipped with indices) 
ranges over Ep\ 

e ::= / Cq ei . . . e„ | z^ (initial expression for a program) □ 

Our transformation techniques take elements of the class {(p, e) | p S P, e S Ep} 
as input. This class contains the following subclasses with .. composition 
expressions, for which we would like to compare the transformation techniques. 

Definition 4 For every i € [ 2 ] let Mi be the class AC or one of its subclasses. 

The , (Mi; M2) is the set {(p, e) | p G P, e G Ep, there are mtts 

mi and m2 in p with mi G Mi, m2 G M2, and there are /i G and 

/2 G such that e = (/2 (/i zq zi . . . z„J z„^+i . . . z^+nj}. □ 

Example 5 Let p consist of niex and nimir- Then, ei = ( ir { x zq) z\) G Ep 
and 62 = ( X ( ir zq zi)) G Ep. Moreover, (p, ei) G ( OPi,z; ( AC — TOP)ij) 
and(p, 62 )g(( AC-TOP)ix, OPi^i). Let to, h G Tc^ a,nd a=[zo/to, zi/h]. 
Then we have eitr /(eicr) and 620" =^Mto|+l*i|-2 □ 

The transformations should preserve the semantics of pairs in { (p, e) \ p G P, e G 
Ep}. This is formalized by the following notion of equivalence. 

Definition 6 For every i G [ 2 ] let {pi, a) G {(p, e) | p G P"*", e G Ep}. The pairs 
(pi, ei) and (p2, 62) are called , , . , . , denoted by (pi, ei) = (p2, 62), if Cp^ = 

Cp2 and if for every substitution a = [v/ty | z; G ar(ei) U, ar{e2),ty G PcpJ> 

/(^pnClO')= /(=^P 2 ; 620”) ■ □ 

4 Deforestation 

The (classical) deforestation technique [ 20 , 5 ] can be seen as algorithmic instance 
of the fold/unfold-technique in [ 1 ]. The presentation of deforestation in Trans- 
formation 7 obeys the syntax of our language P and is similar to e.g. [ 18 ]. Defor- 
estation mimics call-by-name reduction steps (unfold-steps) on expressions with 
variables, i.e. with “values” which are unknown at transformation time. There- 
fore, deforestation defines new functions by case analysis, whenever it has to 
handle an unknown value v in the recursion argument of a function application. 
Roughly speaking, it uses an expansion of v by every possible constructor. 
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For . programs [20] , in which essentially every occurrence of a function 

in the right-hand side of an equation is only applied to variables, the termination 
of deforestation is ensured by using already defined functions, whenever this is 
possible (fold-steps). The programs in P are not treeless, since mtts may use 
nesting of terms in parameter positions. To ensure termination of deforestation 
also on P, we assume that every context argument of a function application is 
implicitly abstracted by a let-expression [20,12], i.e. we handle (/ Xi 
as if it were written like et Vi = ti, . . . ,Vn = tn- n {f Xi vi . . . Vn)- We do not 
choose explicit let-expressions, since this would expand the description of the 
composition techniques and the comparison in Sections 5 and 6, respectively. 

Transformation 7 Let (p, e) S ( AC; AC). We define a function T> which 
takes e (and implicitly p) as input. T> assumes an implicit abstraction with let- 
expressions and is specialized to handle composition expressions. It can be shown 
that the five rules for T> perform a complete and disjoint case analysis on the set 
T of expressions over Cp, Fp, and V, which are encountered starting with a com- 
position expression. In particular, T does not contain expressions of the forms 
if 3 if 2 (/i and (/2 (/i (c The symbols v, c, /, and t 
(also with indices and apostrophes) range over the sets V, Cp = {ci, . . . , c^}, Fp, 
and T, respectively. The notation / and / 1/2 in rules (4) and (5), respectively, 
refers to a function / and / 1 / 2 , respectively, which either is constructed as spec- 
ified behind “where” (“where” does not occur in the transformation result), or 
which was already constructed. In this way D|e] delivers a new program p' € 
and a new initial expression e' for p' . We denote the transformation result (j)' , e!) 
also by ef{p,e). 



(1) Vlvj 




= V 


(2) Vic h... 


tkj 


= C P[til...P[tfc| 


(3) PI/ (cti 


...tk) 


= p[ hs{f,c)[x^/ti\[yi/t'i\j 


(4) Vlf V . 


■•■41 


= f V Vlt[j . . .Vft'J where 



/ (ci xi . . . XfcJ yi . . . p„ = T>1 hs{f, Cl)] 



f {cq xi . . .XkJ yi ■ . - yn = T>1 hs{f, c,)] 

(5) T >|/2 (/i V ti . . t'l . . .4J = / 1/2 V V{ti \ . . Dpil . ■■'Dlt'nJ, 

where 

/ 1/2 (ci . . .XfcJ yi . . . Pni+n 2 — V[h ( hs{h,ci)) 2 /ni + l • • • yni+n2\ 

/ 1/2 {cq a:i . . .XfeJ Pi . . . Pni+n 2 — ^ 1/2 ( hs{fi, Cq)) ym +1 ■ ■ ■ 2/^1+712] 

Lemma 8 For every (p, e) € ( AC; AC) we have (p, e) = ef{p,e). □ 

Instead of proving Lemma 8 formally, we argue by showing the similarities and 

differences of Transformation 7 and deforestation as it is described e.g. in [18]; 
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T> terminates, since for the composition of two mtts mi and m 2 with hi and 
/i 2 functions, respectively, it constructs at most / 11/12 + /ii + /12 functions. The 
rules (4) and (5) reflect the implicit abstraction of context arguments by let- 
expressions and differ from the usual presentation (cf. e.g. rule (5) in [18]). 
In the following we show that rule (4) performs the same transformation as 
transformation rules in the literature, which can handle explicit let-expressions 
(cf. e.g. [20]). For rule (5) an analogous argument holds. 



Vlf vt'i...t'J 

= Vl et vi = t[, . . . ,Vn = n {f vvi . . . u„)] 

= etVi= ..,Vn= Vlt'J. n Vjf VVi...Vnj 

= etvi= T>|ti], . ..,Vn= T>|4]. n{f vvi...Vn) where . . . 
= f V Vlt[j . . .Vlt'J where ... 



(let-abstraction) 
{V on let-expr.) 
{V on function) 
(inlining of let) 



Note that in contrast to e.g. [18] we do not introduce a new function in 
rule (3) for two reasons: On the one hand mtts do not allow, ,, _ in the 

sense of [18], which are defined without pattern matching. On the other hand, the 
introduction of f-functions does not contribute to the elimination of intermediate 
results. The omission of an f-function in rule (3) can cause a later termination 
of T>, but does not affect termination at all, since at the critical steps, where 
an expansion of variables is performed, new functions are introduced. Note also 
that f-functions which are not . later [18], increase the number of 
reduction steps. 

For initial expressions like ( pp Zq ( pp zi 2 : 2 )), which are , 

- , our deforestation algorithm would behave differently from the algo- 

rithm described in [20], since ( pp zq { pp zi Z2)) would be treated as if it were 
the expression et v = { pp z\ Z2)- n { pp zq v). 



Example 9 Let p G P consist of rriex and rrimir and let ei = ( ir { x zq) z\) 
€ Ep. Then, V\ ir { x zq) zij = ( xmir zq T>|zi]) = ( xmir zq zi) where 



xmir {A x\) y\ 

= V{ ir ( hs{ x,A)) j/i] 

= X>| ir {B { X xi)) yij 
= VlB ( ir { X xi) {B j/i))] 
= BT>1 ir { X xi) {B yi)] 

= B ( xmir X\ T>\B yi]) 

= B ( xmir xi {B T>|yi])) 

= B { xmir X\ {B yi)) 



xmir {B x\) yi 
= . . . = A { xmir X\ {A yi)) 

xmir N yi 

= V\ ir { hs{ x,N)) yi] 

= Vl irNyi] 

= nyil 

= yi 



The new initial expression is ei^d = ( xmir zq z\) and the new program pi^d 
contains the above three equations for the function xmir (where both sides of 
every equation are underlined). Thus, ef{p,ei) = (pi,d,ei_d). Let to,ti € Tc^ 
and a = [zo/to, zi/h]. We have epdcr /(epdcr). 



□ 
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Example 10 Let p G P consist of niex and nimir and let €2 = { x ir zq zi)) 
G Ep. Then, T >1 x ( ir zo ^i)] = ( irex zq I1|zi]) = ( irex zq zi) where 



irex {A x\) y\ 


irex {B x\) pi 


= V{ x{ hs{ ir,A))j 


= . . . = A ( irex x\ {B pi)) 


= V{ X {A ( ir xi (A pi)))] 

= VlB{x{ irxi{Ayi)))\ (-k) 


irex N pi 


= BVl X {. ir xi {A pi))] 


= V\ X { hs{ ir, A^))] 


= B {. irex x\ T>\A pi]) 


= Vl X pi] 


= b \ irex Xi {AV\yi})) (-) 


= xyi 


= B {. irex xi {A pi)) 


where x is defined as in m, 



The symbols (+) and (— ) are explained later. The new initial expression is 62, d = 
( irex Zq zi) and the new program p2,d contains the above three equations for 
the function , irex and the equations from uiex- Thus, ef{p, €2) = {P2,d, ^2,d)- 
Note that p2,d S {P'^ — P), because of the equation , irex N yi = x y\. Let 
to,ti G Tc^ and a = [zo/to, We have 62. dC f{e2,dcr)- □ 

5 Composition Techniques 

In [17] it was shown that the composition of two tdtts can be simulated by only 
one tdtt. This result was generalized in [4], where composition techniques are 
presented which construct an mtt for the composition of a tdtt with an mtt, 
and of an mtt with a tdtt, respectively. In [4] it was also proved that there is no 
such construction for the composition of two mtts, since the class of functions 
which are computed by mtts is not closed under composition. The central idea 
of the composition techniques for the composition of two tree transducers mi 
and m2 is the observation that, roughly speaking, intermediate results are built 
up from right-hand sides of mi. Thus, instead of translating intermediate results 
by m2, right-hand sides of mi are translated by m2 to get the equations of a 
new tree transducer m. For this purpose, m uses Fmi x Pm2 function set. In 
the following, we abbreviate every pair {f,g) G Fmi x Fma by fg. 

The composition technique for the composition class ( OP; AC) is given 
by Transformation 1 1 . It will be necessary to extend the call- by-name reduction 
relation to expressions containing variables (they are handled like 0-ary construc- 
tors) and to restrict the call-by-name reduction relation to use only equations of 
a certain mtt m, which will be denoted by =>m- 

Transformation 11 Let (p, e) G ( OP; AC). Let mi be a tdtt in p, let m2 
be an mtt in p, let /i G Fm] and /2 G Fm2^^\ such that e= (/2 (/i zq) zi . . . z^^). 
We construct a new program p' and a new initial expression e' for p' as follows. 
The transformation result (p^ e') is also denoted by om{p,e). 

1. From m2 we construct an mtt m2 which is able to translate right-hand sides 
of equations of mi. Note that m2 is not part of p'. 
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— 7712 contains the equations of m 2 . 

~ For every g G and / G Fm} we add the following equation to m 2 : 

9 if xi) yi-..yn = fg xiyi-.-Vn 

where every / G F^l and fg with / G Fm\ and g G is viewed as 

additional unary and (n + l)-ary constructor, respectively. 

2. p' is constructed from p by replacing mi and m 2 by the following mtt m 

with = {7ff I / G 5 e F^+% For every g G F^+^\ f G 

and c G Cp^\ such that / (c xi . . . Xk) = hs{f, c) is an equation in mi, m 
contains the equation 

fg{cxi...xk)yi...yn= , 9 ( hs{f, c)) yi . . . y„) 

3 . e' = (/1/2 zo zi . . □ 



Lemma 12 For every (p,e) G ( OF; AC) we have (p,e) = om(p,e). □ 

We omit the proof and only mention that in [4] another construction was 
used, which first splits the mtt into a tdtt and a device for handling parameter 
substitutions, then composes the two tdtts, and finally composes the resulting 
tdtt with the substitution device. We get the same transformation result in one 
step by avoiding the explicit splitting and joining of substitution devices. 



Example 13 Let p G P consist of niex and m^ir and let Ci = (, ir { x zg) zi) 
G Ep. The mtt fhmir is given by the following equations: 

ir{Axi)yi=A{ irxi(Ayi)) ir N yi = jq 

ir {B a:i) y\ = B { ir x\ {B yi)) ir { x x\) yi = xmir X\ y\ 



The new program pi_c contains only one mtt with the following equations: 



xmir {A xi) y\ 

= ix { hs{ x,A))yi) 

= ir {B { x xi)) yi) 

= f ( ir { x xi) {B 7/i))) 

= B { xmir X\ {B yi)) 



xmir {B x\) y\ 

= . . . = A ( xmir x\ {A yi)) 



xmir N y\ 
= ... = 91 



The new initial expression is ei_c = ( xmir zg zi). Thus, om(p,ei) = (pi,c,ei_c). 
Let toAi G Tc^ and a = [zg/fo, zi/ti]. We have eyccr =^p°l - /(eycc). □ 

The composition class ( AC — TOP; OP) is handled by Transformation 14. 
We use the additional observation that for fi G Fm ^ , /2 G F^^ > and an instance 
of an initial expression (/2 (/i zg zi...z„)), the results of the instances of 
(/2 zi ), . . . , (/2 z„) instead of the instances of zi, . . . , z„ will occur in the final 
output. Thus, the context arguments of the functions of the new mtt represent 
the translations of the context arguments of the functions of m± by m 2 . 
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Transformation 14 Let (p, e) S ( AC — TOP; OP). Let mi be an mtt 
in p, let m2 be a tdtt in p, let /i S and /2 S Fml, such that e = 

if2 ifi zq zi . . . Zni)). Let gi, ... ,ph be a fixed order of all functions in We 
construct a new program p' and a new initial expression e' for p' as follows. The 
transformation result (p', e') is also denoted by om{p, e). 

1 . From m2 we construct a tdtt m2 which is able to translate right-hand sides 
of equations of mi. Note that m2 is not part of p' . 

— 7712 contains the equations of m2. 

~ For every g G Fm} and / G we add the following equation to 777,2: 

(*l) g if Xl X2 .. .Xn+l) 

= fg Xi igi X2)...ighX2) (51 Xn+i) ...{gh a:„+i) 

where every / G Fm^^^ and fg with / G and g G F^l is viewed 

as additional (77 -I- l)-ary and [hn -I- l)-ary constructor, respectively. 

— For every g G F^l and for every yj which occurs in right-hand sides of 
equations of mi add the following equation to 7712: 

(*2) g Vj = yj,g 

where every yj and every yj^g are viewed as additional 0 -ary constructors. 

2 . p' is constructed from p by keeping m2 and by replacing mi by the following 

mtt m with = {fg\f G G F^^}: For every g G F^2, 

f G Fm^^\ and c G Cp^'^ such that f {c Xi . . . Xk) yi . • . J/n = hs{f, c) is an 
equation in mi, m contains the equation 

fg (c xi ...Xk) 7/1, ...yi ,gh Dn.gi ■ ■ ■ Vn.gh — / (=^m2 ! 5 ( hs{f,c))) 

3 - e' = (/1/2 zo (gi zi)...{gh zi) {gi J . . . {gh z^)) □ 

Note that e' is no composition expression. The following lemma is a conse- 
quence of a result in [ 4 ] and will not be proved here: 

Lemma 15 For every (p, e) G ( AC— TOP; OP) we have (p, e) = om{p, e).D 

Example 16 Let p G P consist of mex and mmir and let C2 = { x { ir zq zi)) 
G Ep. The tdtt rhex is given by the following equations: 

X {A xi) = B { X xi) X N = N X i ir x\ X2) = irex x\ { x X2) 

X {B xi) = A{ X xi) xyi= yi^ex 

The new program p2,c contains mex and a new mtt with the following equations: 



irex (A xi) 7 /pex 


irex iB xi) yi^ex 


= xi hsi ir,A))) 


= .. . 


= /(^mxx) xiAi irxi iAyi)))) 


= A{. irex xi [Ayi^ex)) 


= fi^rh,^,B i X i irxiiAyi)))) 

= /(^mxx)- 5 ( irex xi i X iA yi)))) (!) 


irex N yi^ex 


= /(^mex : B ( irex Xi (F ( x yi)))) 


= . . . 


= B ( irex xi (F pi,ex)) 


— yi,ex 
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The new initial expression is 62, c = ( irex zo ( x z\)). Thus, om(p, 62) = 
(P2,c,e2.c)- Let to,ti e Tc^ and a = [zqAo, W e have 62 ,cCT 
/(e2,cCr). □ 

6 Comparison 

Although the transformations of Sections 4 and 5 work on nonlinear programs as 
well, we restrict the following comparison to linear mtts, since nonlinear function 
definitions can cause a deterioration by deforestation [20] and also by composi- 
tion. We will use the following notions to compare efficiencies. 

Definition 17 For every i G [ 2 ] let G {(p, e) | p G P+,e G Ep} such 

that (pi,ei) = (p 2,62). We call (pi,ei) . . . . ( . . . - - - , 

respectively) (^2,62), denoted by £{pi,ei) = £{p2,e2) {£{pi,ei) > £(^2,62), 
respectively), if for every a = [v/E | u G , ar(ei) U, ar{e2),tv G TCpJ and for 
every ai,cr,a2,dr € W with CiCr /(cicr) for every i G [ 2 ], 

ai,(T = Q!2 .<t (ai.CT < a2.cr, respectively). 

We call (pi,ei) . . ... (^2,62), denoted by £{pi,ei) > £(^2,62), if 

£{pi,ei) > £{p2,e2) and there is cr = [v/ty | ?; G , ar(ei) U, ar{e2),ty G TcpJ 
and ai.cr,a2,(T G W with eta ^pl'” - for every i G [2] and 

Q!l,dr < Q!2,cr- 

We will compare the transformations on the composition class ( ACp, ACi). 
It turns out that there are different results for its three disjoint 
subclasses ( OPp, ACi), (( AC — TOP)i; OPi), and (( AC — TOP)i\ 
( AC-TOP)i). 



6.1 Where Deforestation and Composition Behave Similarly 

Example 18 Let p € P consist of niex and rrimir and let ei = ( ir { x zq) zi)- 
Examples 9 and 13 show that deforestation and the composition technique trans- 
form (p, ei), apart from function renaming, into the same program and initial 
expression. In particular, £{ e/(p, ei)) = £{ om(p, ei)) > f(p, ei). □ 

This observation can be generalized as follows. 

Lemma 19 For every (p, e) G ( OPi,j; ACij): ef{p,e) = om{p,e) 

(apart from function renaming). 

Proof Idea. Let {pd-^^d) = ^f{p,^) and {pc,ec) = om{p,e). Let toi be 

a tdtt in p, m2 be an mtt in p, fi G Fm}, and /2 G such that e = 
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(/2 (/i zq) zi . . -Zn)- Let c S C^\ Deforestation generates in the body of the 
where-clause in rule (5) the equation 

/1/2 {cxi...xk) yi-..yn = T>lf 2 ( hs{fi,c)) yi . . .y„] 

for pd and composition generates by 2. in Transformation 11 the equation 

fif 2 {c xi . . .Xk) yi ■ . - yn = hs{fi,c)) yi . . .yn) 

for Pc- Identifying /1/2 with /1/2, these two equations are equal, since 

X>|/2 r ri . . ,r„] = . r ri . . .r^), 

for every right-hand side r of mi and for every right-hand sides ri , . . . , of m 2 
in which recursion variables are instantiated by right-hand sides of TOi, can be 
proved by an induction on r € i?. Additionally, an inner induction proof on the 
set of in this way instantiated right-hand sides of m2 has to be performed. □ 

If mtts with more than one function are considered, then Lemma 19 remains in 
principle valid, but the composition technique sometimes constructs new func- 
tions which are never used to evaluate instances of the new initial expression. 
Deforestation prevents the construction of superfluous functions, since it mimics 
the call-by-name evaluation of an arbitrarily instantiated initial expression. 

Lemma 20 For every (p,e) G ( OPp, ACi): ef{p,e) = om{p,e) 

(apart from superfluous functions and apart from function renaming). □ 

Since deforestation does not deteriorate the efficiency (cf. e.g. [20,18]), we get: 

Corollary 21 For every (p,e) G ( OPp, ACi): 

e/(p,e))=f( om(p,e)) > £(p,e). 



6.2 Where Composition is at Least as Good as Deforestation 

Example 22 Let p G P consist of mex and mmir and let 62 = { x { ir zq zi)). 
We get the result £{ om{p, 62 )) > £{ e/(p, 62)) > £’(p, 62) from Examples 5, 
10, and 16. 

Example 10 shows that on the one hand deforestation is successful in remov- 
ing the intermediate constructor “outside” the recursive call of ir by replacing 
Ahy B (cf. step marked (-I-) in Example 10). 

On the other hand, deforestation cannot remove the intermediate constructor 
“inside” the recursive call of, ir (cf. step marked (— ) in Example 10), since the 
function x does not reach the context argument of, ir. In contrast to this, the 
step (!) in Example 16 shows, that x moves into the context argument of, ir, 
thereby removing also the “inside” intermediate constructor. □ 
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The different behaviour of the transformations is caused by the different strate- 
gies to handle the “meeting” of two functions. Rule (5) in Transformation 7 shows 
that deforestation generates a new function and simply moves into the context 
arguments without changing them, whereas equation (*i) in Transformation 14 
shows that composition additionally sends the functions of m 2 into the context 
arguments. Maybe this observation allows an improvement of deforestation by 
integrating the behaviour of (*i) into rule (5). The equation (*i) also has one 
negative aspect: Since it copies context arguments according to the number of 
functions of m 2 , the produced program can be nonlinear. We do not know yet, 
how the efficiency (counting call-by-need reduction steps) of programs, which are 
constructed in this way, is related to the original programs. Hence, we restrict 
the statement of the following lemma to tdtts with only one function. 

Theorem 23 For every (p,e) € (( AC — TOP)i; OPi^i): 

£{ om{p,e)) >£{ ef{p,e))>£{p,e). □ 

Before we give the proof idea, we would like to discuss, for which composition 
classes we obtain strict improvements in Theorem 23. 

Example 24 Let p G P consist of m^x, "niapp, and mrev 

— For e = { X { pp zq z\)) we have £{ om{p,e)) = £{ ef{p,e)) > £{p,e), 
since already deforestation completely removes the intermediate result. 

— For e = ( X { ev Zq z\)) we have £{ om{p,e)) > £{ ef{p,e)) = £{p,e), 

since deforestation fails in removing the intermediate result, whereas com- 
position completely removes it. □ 

The different results in Example 24 are caused by the different structures of right- 
hand sides of pp and ev. For example, hs{ pp,A) has a constructor outside 
and no constructor inside the recursive function call, whereas in hs{ ev, A) it 
is vice versa. Roughly speaking, deforestation can only eliminate intermediate 
constructors, which occur outside the topmost function applications of right- 
hand sides, whereas composition additionally eliminates intermediate construc- 
tors inside the topmost function applications. Following this idea, we define a 
decomposition of right-hand sides into a top-part and bottom-parts, which will 
be important to state a refinement of Theorem 23 and to prove Theorem 23. 

Definition 25 Let r G R. Define . op{r) G Tc{yi, ■ ■ ■ , yn, ui, . . . , Um), for every 
i € [m] define fk^ G and Xk^ G X, and for every j G [rii] define , otij{r) G 

R, such that r = . op{r)[ui / {fk^ Xk^ . oU^i{r ) .... oti_„,(r))]. □ 

Example 26 If r = {A ( ir x\ {A j/i))), then .op{r) = {A ui), fk^ = ir, 
Xki = xi, and . otpi(r) = {A y{). Thus, |. op{r)\c = 1 and |. otpi(r)|c = 1. □ 

Theorem 27 Let (p,e) G (( AC — TOP)i; OPi^i). Let mi be an mtt in p, 
m 2 be a tdtt in p, fi G and /2 G Pm 2 , such that e = (/2 (/i zq • ■ • -^ni))- 
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— If there is c S Cp with |. op{ hs{fi,c))\cp > 0, then 

ef{p,e)) > £{p,e). 

— If there are c G Cp, and i,j > 0 with |, otij{ hs{fi,c))\cp > 0, and if 

ar(l) = , ar(r) for every equation / = r of mi and m 2 (nondeleting condi- 
tion), then 

£{ om{p,e))>£{ ef{p,e)). □ 



Proof Idea of Theorems 23 and 27. Let (p, e) G (( AC —TOP)i] OPi ;), 
(Pd,ed) = ef{p,e), and (pcSc) = om{p,e). Let mi be an mtt in p, m2 be a 
tdtt in p, fi G g G such that e = (g (fi zq . . . Zn^))- 



Let / G and c G Cp'^’ . We abbreviate . op( hs{f,c)) by .op and 

, otij{ hs{f,c)) by ^ otij. Thus, hs{f,c) = .op[ui/{fki Xk^ ^ oti^i-... 
Deforestation generates (if demanded) the following equation for pd'. 



't(fc) 



fg {cxi ... Xk) yi-.-Vn 

= Vlg (. op[ui/{fki Xki . oti^i ...^ oti^m)])] (Body of where in (5)) 

= f{^m 2 ,g- op)[{g yj)/T>lg vMig ui)/Vlg (/*, Xk^ . oU^i ...^ ot*,„.)]] 

(Rules (2) and (3)) 

= f{.^m2,g-op)[{,gyj)/{,gyj)][{,gui)lV{g{fkiXki. oU^i...^ oti,„,)]] 

{T^la Vjl = {9 Vj)) 

= f{^m 2 ,g -op)[{g u^)/{fkig Xk,Vl oti,„J)] 

(Rule (5)) 

= f{^m 2 ,g-op)[igUi)/{fkigXki. oUp.... otj^m)] {Flrj =r for r e R) 

The statements T>lg j/j] = {g yj) and T>\r\ = r do not reflect that here functions 
of m 2 and mi, respectively, are “reproduced” in general. T>\r\ = r can be proved 
by an induction on r G i?. Composition generates the following equation for 

fg (C Xi ...Xk) yi,g...yn,g 

= fi=^fh 2 ,g (- op[ui/{fki Xki . oti^i .... oti^m)])) (2. in Transformation 14) 

— f (^ m2 ; 9 ' ^P) [(.9 / f (^ m2 ; P {fki Xk^ . oti^i . . . , oti ji- ))] 

(Definition of m 2 ) 

= f{^m2,g -op)[{g yj)/yj,g] 

[{9 u^)/{fki9 Xkj /(^ 7712 1 9 ' ■ ■ ■ /(^ m 2 1 g . 0^2, ni))] 

((* 1 ) and (* 2 ) in Tr. 14) 

Let ti, . . . ,tk,t'i, . . . ,t'n G Tcp. Let a reduction of p start with the step 

g (/ (c ti ...tk) t'l . . .4) ^p g (. op[ui/(fk, Xk, . oU^i .... oti^ra)])[xi/ti][yi/t'i]. 

The continuation of this reduction will in particular force the evaluation of (p . op) 
and of some (p . otij). The corresponding first reduction step of pd is 

f 9 [c ti . ■ . tk) ti . . . ^Pd 

f{^Tn2,9 ■op)[(g yj)/igt'j)][{g u,)/{{fk,g Xk, . ot*,i.... oti^.„„)[xi/ti][yi/t[])] 
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It saves the steps for the evaluation of {g . op) . The corresponding first reduction 
step of Pc also saves the steps for the evaluation of the {g . otij): 

7 g{cti...tk) {gt[)...{gt'J 

[{g Ui) /{{fkiP Xki otip) . . . /(=^rn2)S'. oti^m))[xi /ti][yi^g / {g ti)])] 

This also holds for corresponding instances of e, Cd, and Cc- The informal expla- 
nation can be seen as heart of an induction proof on Tc^ , for which additionally 
an inner induction proof on the set of right-hand sides of mi is needed. The 
proof also shows that, if subtrees are deleted, then this affects the three re- 
ductions in the same way. If for some c G Cp we have \. op{ hs{fi,c))\cp > 0 
(and |. otij{ hs{fi,c))\cp > 0 for some i,j > 0 such that . otij{ hs{fi,c)) is 
not deleted by =^p), then the precomputation of {g . op{ hs{fi,c))) (and of 
{g . otij{ hs{fi,c))), respectively) really saves reduction steps. This holds at 
least for substitutions of zq in e by a tree which has the symbol c at its root. □ 

6.3 Where Deforestation is at Least as Good as Composition 

Since for every (p, e) G (( AC—TOP)i; ( AC—TOP)i) the composition tech- 
niques are not applicable, we define om{p, e) = (p, e) and get as consequence: 

Theorem 28 For every (p, e) G (( AC—TOP)i;{ AC—TOP)i): 

e/(p,e))>£( om{p,e)) = £{p,e). 

Also here we could distinguish composition classes, which are either improved 
or not improved by deforestation. Since this leads to an analysis of deforestation 
and does not contribute to our intended comparison of the two techniques, we 
only give representative examples for these classes: 

Example 29 Let p G P consist of rriapp and nirev 

— For e = ( pp ( pp Zq Zi) Z2) we have £{ ef{p, e)) > £{p, e). 

— For e = ( ev { ev Zq zi) Z2) we have £{ ef{p, e)) = £{p, e). □ 

7 Future Work 

We have presented qualitative comparisons of deforestation and composition 
techniques for certain composition classes. A quantitative analysis (also by using 
more exact efficiency measures) would be useful, in order to calculate speedups, 
which are realized by the transformations. Moreover, we would like to extend 
our research to nonlinear programs and to specify composition classes, for which 
nonlinearity is harmless with respect to deforestation and composition. 

Other methods for the elimination of intermediate results should be inte- 
grated into the comparison. Therefore, on the one hand we want to analyze 
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. . . (or: . , ) , . [11]. In [10] already an informal compar- 

ison between classical deforestation and cheap deforestation is performed. On 
the other hand we would like to inspect composition methods for . . 

. . [6], which are abstractions of . y , , . [14]. Such com- 

position results were presented e.g. in [6,8,9]. They can also be used for the 
composition of a restricted class of mtts [15]. For the intended comparison, we 
consider ....... . . [16] as suitable integration formalism. 
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Abstract. This paper reconstructs and extends the automatic verifi- 
cation technique of Le Metayer, Proving properties of programs defined 
over recursive data structures (ACM PEPM ’95), based on a backward 
abstract interpretation. 

To show the effectiveness of extensions, we show two examples of the 
declarative specifications of sorting and formatting programs, which are 
directly and concisely expressed in our specification language. 



1 Introduction 

Program errors cause failures during execution that can be classified into three 
categories. 

1. Execution eventually stops as a result of illegal operations. 

2. Execution does not terminate. 

3. Execution results are not what was intended. 

Errors of the first kind are detected by type inference, with such languages as 
ML. In addition, although termination is in general undecidable, errors of the 
second kind can be automatically prevented by several techniques, such as simple 
termination [12,13], termination analysis [16], and dependency pairs [2]. 

The third kind of error cannot be prevented without a specification language, 
and there is always a trade-off between expressiveness and feasibility. If the 
aim is to express everything, it is easy to fall into the trap of undecidability. 
Moreover, too much expressiveness may make users hard to learn. For compile- 
time error detection, an automatic verifier that functions without any human 
guidance is desirable even if it verifies only partial specifications. Then the user 
can concentrate on what kind of properties, under the limitation of a simple and 
restricted specification language, properly approximate the program behavior. 

By restricting both properties and languages, Le Metayer developed an au- 
tomatic verification technique [19]. Its target language is a strongly- typed first- 
order functional language with product types and recursive types. The impor- 
tant restriction is that the conditional part of an if-expression contains only basic 
predicates (such as null, leg, geq, and equal) without any functional symbols. 
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He defines a language which prescribes a class of , - , predicates over 
recursive types. These predicates are constructed by predicate constructors from 
basic predicates on base types. As an example, his system expresses that a sort 
program returns a list of decreasing values (if the sort program terminates) and 
automatically verifies it. This property is called . ... of the sort program, 

which is expressed by true Wgeq{sort X) in our specification language. Note 
that the termination of the sort program is not verified; this verification is left 
to a termination analysis. 

Similar ideas to those of uniform predicates are also found in Refs. [15,17,3,21] ; 
however, the significant differences are that 

~ binary predicates are allowed in constructing predicates, and 
— free variables in binary predicates are allowed. 

The former extends the expressiveness of target properties from other flow anal- 
yses. The latter maintains the power of inter-functional inferences. However, 
the expressive power of the specification language is still fairly restricted as a 
verification; for instance, the input-output relation cannot be described. 

This paper reconstructs and extends the automatic verification technique 
of Le Metayer [19] based on a backward abstract interpretation [11,1,7]. The 
termination and soundness proofs of the verification are naturally derived from 
the formalization as a backward abstract interpretation. 

Extensions are achieved by (1) using the input variable in function prop- 
erties, (2) introducing new predicate constructors, and (3) using uninterpreted 
function/predicate symbols. They are demonstrated by verifying the sorting and 
formatting programs. The first and the second extensions expand the ability of 
the specification language so that it covers another major specification of the 
sorting program; namely, / , _ . , i.e., the input and the output are 

the same . . This is expressed by true ^ \/i3requal A y r^iequal{sort X). Note 
that since our specification language cannot express the number of elements in a 
list, our algorithm cannot detect the full specification of sort, called, - , 

i.e., the input and the output are the same , , _ .. 

The third extension expands the range of both target programs and the spec- 
ification language. The expansion of target programs is achieved by loosening 
the restrictions on the conditional part of an if-expression. The running exam- 
ple is format, which formats a given sentence (expressed as a list of strings) 
to a specified width. The technique behind this extension is the use of , - . 

. . , _ . We also show how partial evaluation will cooperate with the 

verification. Other major specifications of format become expressible by the use 
of , . - . . . ... - . . This technique drastically expands the expressive 

ability, such as the specification that the order of words is preserved by format. 

This paper is organized as follows: Section 2 defines programming and spec- 
ification languages. Section 3 provides the verification algorithm based on a 
backward abstract interpretation. The termination and soundness proofs are 
also given. Section 4 demonstrates the verification of . . of the (simple 

but inefficient) sort program to explain the algorithm. Section 5 presents exten- 
sions and demonstrates the verification of major specifications of the sorting and 
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formatting programs. Section 6 discusses related work and Section 7 concludes 
the paper and discusses future work. 

2 Preliminaries 

2.1 Programming Language 

The target language is a strongly-typed first-order functional language with ML- 
like syntax, in which product types and recursive types, such as lists list{A) = 
fxa.nil + A X list(a), are allowed. We use :: to mean infix cons, @ to mean infix 
append, and [ ] to mean a list, namely, [01,02,03] = oi :: (02 :: (03 :: nil)). The 
semantics of the language is given by an ordinary least fix-point computation. 
We assume that the language is strict, but the same technique can be applied 
to a lazy language as well. The precise syntax and semantics of the language are 
shown in Fig. 1 and Fig. 2. Parentheses in the syntax are used for either making 
pairs or clarifying the order of applications of infix operators. Basic concrete 
domains DbooI and Djnt are flat cpo’s (as usual), and the other concrete domains 
Da of type a are constructed by the list and pair constructors. The interpretation 
tp of expressions has the hidden argument, i.e., for simplicity the environment 
fve of function variables are omitted in Fig. 2. 



The language of expressions 

E = X \ C \ (Ei,E 2) \ El :: E2 \ f E \ op E \ (E) \ 

if Cond then Ei else E2 \ let val x = Ei in E2 end | 
let val {x,y) = Ei in E2 end | let val x y. xs = Ei in E2 end 
Cond = pu X \ ph {x, y) 

{ E € Exp expressions op € Prim primitive functions 

C € Const constants Pu,Pb £ Pred basic predicates 

X £ Bv bound variables f £ Fv functional variables 

The syntax of programs Prog = { fun fi Xi = Ei ; } 

The language of types 

T =Tg\Tf Tf = Tg-^Tg 

Tg = Tu\Tp\ Tr Tp = TgX Tg 

Tr = pLa.nll +Tg a Tp = t (basic types) 

Fig. 1. Syntax of Programming Language. 



An important restriction is that the conditional part of an if-expression must 
consist only of basic predicates without any functional symbols. Section 5 dis- 
cusses how this requirement can be loosened. Until then, we use only null as the 
unary basic predicate on lists, leq, geq, and equal as the binary basic predicates 
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ifl { fun fi Xi = Ei ; } ] 



= fve whererec 



fve = [(Ayi • • • yn.if {bottom? yi ■ ■ ■ yn) 



then _L else -tplEijlyj /xj])/ fi] 



iplCJbve 
iplxjbve 
tplop EJbve 
ip[Pu xjbve 
'tPlVb {x,y)jbve 
iflf Ejbve 
i;l{Ei,E2)jbve 
'iplEi E2jbve 



= CcIC] 

= foue[a;] 

= ^flopj{tplEjbve) 

= ^plPujibvelxj) 

= ^plPbj{bvelxj,bvelyj) 

= fyelfUHEjbve) 

= {-iflEijbve, iflE2jbve) 

= {'tplEijbve) {ijjlE2]bve) 



'ipl'if Cond then Ei else E2}bve = if {bottom? {tplCondJbve)) then _L 

elsif tplCondjbve then tplEiJbve else tplE2}bve 
■i^llet val X = El in E2jbve = tp[E2}{bve[iplEijbve/x]) 
ifllet val {x,y) = Ei in E2jbve = iflE2j{bve[iplEi}bve/{x,y)]) 
ifllet val X xs = Ei in E2}bve = -!/’[-E2](fete[i/’[-Ei]&we/a; :: ®s]) 
bottom? yi-'-yn = {yi =-L) V • ■ ■ V (i/n =-L) 



on integers, :: as a binary primitive function, and nil as a constant. The type 
description in a program is often omitted if it can be easily deduced by type 
inference. 

For technical simplicity, we also set the following restrictions. 

— Basic types are Int and Bool. 

— Product types and recursive types are pairs and lists, respectively. 

— Each function is unary, i.e., pairs must be used to compose variables. 

The third restriction means that binary functions and predicates are respectively 
regarded as unary functions and predicates which accept the argument of pair 
type. This assumption can easily be extended to a more general setting, for 
instance, with tuple types. 

Values are denoted by a, 6, c, • • •, lists by as, bs, cs, ■ ■ •, and lists of lists by 
ass,bss,css,- ■ We also assume that variable names of input variables and 
locally defined variables are different. The following functions present a sorting 
program with types sort : int list int list and max : int list —>■ int x int list. 

^ as is a reserved word of ML, but we ignore it. 



where < 



' 'll) : {Fve ~^)Exp — > Bve — > D 
ipp : Prog Fve 
fve € Fve = Fv D ^ D 
. bve G Bve = Bv — > D 



: Prim ^ D —> D 
^p : Pred — > D ^ Bool 
: Const — > D 



Fig. 2. Semantics of Programming Language. 
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Pf 


= Pa X^P^ if X) 


properties of functions 


Pg 


= predicates in Pq without bound variables 




Pg 


= Ps 1 Pp 1 true 1 false 


ground properties 


Ps 


= Pu\Pr 


unary predicates 


Pr 


= yPu 1 VPg \ P^ \ PrAPrI Ppy Pr 


properties of lists 


Pp 


= Pb \ pp\ Ps X Ps \ V.Pp 1 ViPp 1 


properties of pairs 




Pp A Pp 1 Pp V Pp 




Pb 


= pb \ Pb \ Pb A Pb \ Pb V Pb 


basic binary predicates 


Pu 


= Pu 1 Pb I Pu A Pu 1 Pu^ Pu 


basic unary predicates 


E 




expressions 


V 


= X \ X \ c 


basic expressions 


X 




(finitely many) free variables 


X 




bound variables 


C 




constants 



Fig. 3. Language for specification of properties. 



fun sort as = if null as then nil else 

let val (b,bs) = max as in b::sort bs end; 

fun max cs = let val d: :ds = cs in 

if null ds then (d,nil) else 
let val (e,es) = max ds in 
if leq(e,d) then (d,e::es) else (e,d::es) end 

end; 



2.2 Specification Language 

The language for specifying properties is constructed by using predicate con- 
structors V, V;, Vr, and V on basic predicates, constants, free variables, and vari- 
ables appearing in a program. Predicate constructors will be extended in Sec- 
tion 5. A basic unary predicate is denoted hy pu, a, basic binary predicate by ps, a 
unary predicate by Pjj, and a binary predicate by Pb- Indexes U and B are often 
omitted when they are clear from the context. As convention, bound variables 
are denoted by a, 6, c, • • • , x, y, z, • • • , as, 6s, cs, • • • , xs, ys, zs, ■ ■ •, free variables by 
X, Y,Z,-- •, constants by C,M,- ■ •, and expressions by E, Ei,E 2 ,- ■ ■■ 

A binary predicate P is transformed into a unary predicate P^ by substitut- 
ing an expression E for the second argument. That is, P^(E') = P{E',E). P 
is defined by P{Ei,E 2 ) = P{E 2 ,Ei). The grammar of the construction of pred- 
icates is shown in Fig. 3. Specification of a function / is expressed with a free 
variable by Q{X) P{f X), which means if input X satisfies Q then output 
/ X satisfies P, when P,Qg Pq . Each input A is a distinct free variable for 
each function and property to avoid name crash. 

Note that negation is not allowed. The meanings and examples of the predi- 
cate constructors V, VpVj., and V are given as follows. 
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— VPc/(xs) iff either xs is nil or the unary predicate Pu{x) holds for each 
element x in xs. 

— ^Pb(xs) iff either xs is nil or VP^ (ys) A VPb(?/s) for xs = y :: ys. 

y[PB{xs,y) and VrPB(cc,ys) are defined by \/P^{xs) and \/P%{ys), respectively. 
The examples are shown in the table below. 



predicate 




geq^{a) 


4 


2 


ygeq^{as) 


[3,6,4], nil 


[3,6,1] 


yileq{as, a) 


([3,6,4], 8), (nil, 8) 


([3,6,4], 5) 


yrleq{a, as) 


(3, [3,6,4]), (3, nil) 


(5, [3,6,4]) 


X geq{as) 


[6,4,3], nil 


[4,6,3] 



For instance, the sorting program is fully specified by the following conditions. 

1. Output must be ordered (called orderedness). 

2. Input and output are the same , , _ . (called preservation). 

Orderedness is expressed as true ^ V geq{sort X). That is, the output of the 
sorting program is decreasing if the input satisfies true (i.e., empty assump- 
tions). For preservation, the weaker condition called weak preservation, i.e., the 
input and the output are the same . , is expressed by 

true ^ {\/i3rCqual A Wr^iequal)^ {sort X). 

with the introduction of additional predicate constructors 3,3;, and 3^ (which 
intuitively mean and respectively), which will be discussed in 

Section 5. Note that only the input variable of a function remains in the scope 
when a function call occurs, thus our definition of properties of functions (Pf) 
is possible (which was neglected in [19]). 

3 Automatic Verification as Abstract Interpretation 

3.1 Verification Algorithm as Abstract Interpretation 

An abstract interpretation consists of an abstract domain, its order, and an 
interpretation (on an abstract domain) of primitive functions [11,1,7]. Our choice 
is a backward abstract interpretation with 

abstract domain a set of predicates (in Fig. 3) satisfying the type, 
order the entailment relation defined in Fig. 4, and 

interpretation defined in Fig. 5. 

Let { fun fiXi = Ei\ } be a program. The verification algorithm is the least 
fixed point computation to solve ^ . equations in Fig. 5. Section 4 explains 

how this algorithm performs on the sorting program. 

The entailment relation C (in Fig. 4) is intuitively the opposite of the logical 
implication. That is, P C Q means that Q implies P. By definition, true is 
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Axioms on basic predicates 

equal = equal leq = geq 
equal{x,x) = true 



rmZZ(nil) = true null{x :: xs) = false 
geq{x,x) = true leq{x , x) = true 



equal C equal^ x equal 



9^1 ^ gsq^ X geq^ leq C leq^ x leq^ 

P\ZP^ X P^ 



\fpy C VP" A P{z,y) ViVrP E (ViVrP)"" X (ViVrP)" 



Transitivity 



Ordinary logical rules on logical connectives 



PAP = P Pi C Pi A P2 

PV P = P Pi V P2 C Pi 

Pi ^ P2 Pi' ^ P2 
Pi A Pi' C P2 A P2 



true A P = P false A P = false 

true V P = true false V P = P 

Pi ^ P2 Pi' ^ P2 

Pi V Pi' c P2 V P2 



Entailment relation of predicate constructors 

P^^P^ list t (Pi A P2) = fPi A tP 2 withte{v.Vi,v.,v} 



Pi ^ Pi' P2 ^ P2 
Pi X P2 C Pi' X P2 



(Pi X P2) A (P( X P^) = (Pi A Pi') X (P2 A Pi) 



P = P Pi A P2 = Pi A p2 Pi V P2 = Pi V p2 Pi X p2 = p2 X Pi 
^ = V,P ^ = ViP (ViP)®=V(P^) ViV,P = V,ViP 

VP(a :: as) = P(a) A VP(as) \/P{nil) = true 

VP{a :: as) = yP°'{as) A VP(as) V P{nil) = true 



Fig. 4. Entailment relation 



the least element and false is the greatest element in the abstract domain. We 
denote by P = Q if P C Q and P 3 Q- The entailment relation may be used to 
trim at each step of interpretation !Z/. Formally, the entailment relation consists 
of axioms on basic predicates/predicate constructors, and ordinary logical rules, 
and their extensions by predicate constructors, as defined in Fig. 4. 

In Fig. 5, let Formula be a set of all formulae constructed from predicates in 
Fig. 3 and bound variables (in the scope of an expression) with logical connectives 
A and V. The disjunction V is regarded as composing branches of the verification, 
i.e., each branch (conjunctive formula) is analyzed independently. 

The projection J, extracts a predicate P, in which a bound variable x (in 
the scope of an expression E) is substituted in a formula. When regarding a 
conjunctive formula 7 as an assignment from bound variables to predicates, 7 lx 
coincides with the restriction to x. For instance, {leq{x,y) A'^{xs)) lx= leqy{x). 
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{ fun fi Xi = Ei ■ } ] 



ncjp 

nxjp 

<Plop EjP 

nf EjP 
n(Ei,E2)jp 

nEi ■: E2jP 

iJ^lif Cond then E\_ else E2\P 
•f'flet val X = El in E 2 jP 
l^^llet val {x,y) = Ei in E2jP 

l^^llet val X y. xs = Ei in E2jP 



fvp whererec 

fvp = [ (APl • • • Pr..mEijPi)U)/fi ] 
true if P{C) 

false otherwise 

P{x) 

nEj(siopjp) 

nEmfvpifjp^^)ei^^) 

I nEijPi A '^'I£;2]P2 
\ ^lEijP^^ V <ElE2jP^^ 

( ^lEijQ A ^lE2jyQ 
\niEi,E2)j'irQAnE2jVQ if P = VQ 

0 [{Cond A <ElEijP) V {^Cond A <I'lE 2 jP)] 

nEijinE2jp) i. 
nEij{nE2jp) 

nEij^Q if (<^^IP2]P)i(....)= V,Q 
nEijyQ if (>f'IP 2 ]P)i.= Q or 
(<^^IP2]P)i..= VQ 



if P = Pi X P 2 
otherwise 

if P = VQ 



{ 'E : {Fvp —^)Exp — > Pred — > Formula 
$ : Prog Fvp 

fvp G Fvp — Fv ^ Pred Pred 



S : Prim — > Pred — > Pred 
Formula — > Bv Pred 

0 : Formula —> Formula 



Fig. 5. Abstract semantics of verification 



Note that the | operator is used when the local definition of x in a let-expression 
is analyzed, thus P = j lx must exclude x. In our specification language, if such 
case occurs then P(x) can be reduced true or false using the entailment relation. 
The ^-elimination operator 0is defined by 

0 [ {Cond A P) V {—•Cond A P') ] = MiQi 

where each Qi satisfies Cond A P C and ^Cond A P' C Qi. For instance, 
0 [ {leq{e, d) A 'ileq'^{es)) V {^leq{e, d) A \/leq^) ] = 'ileq‘^{es) V 'ileq^{es). 

The interpretation of a function call 

Elf EjP = E[E\{{fvplflP^^)e^^) 

requires another operation, called /Jry-expansion (similar to the substitution cal- 
culus in higher-order rewrite systems [24]). When a function / is called in an 
expression E, bound variables (except for an input variable to /) become out 
of the scope. Thus, if a predicate P contains a bound variable, then it must be 
replaced with a free variable and the substitution to the free variable must be 
kept. They are P^^ and 9^^. For instance, Eff Ej'dleq'^ creates P^^ = \/leq^ 
and 9^^ = [Z <— &]. 
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Theorem 1. . . _ y / - - - 

, Basic predicates, variables, and constants appearing in a pro- 
gram are finite. A free variable is introduced as a substitute for a bound variable 
only when function-calls; thus, only finitely many free variables are used dur- 
ing verifications. Since each predicate constructor enriches types, once types of 
functions are fixed only finitely many applications of predicate constructors are 
possible. The finiteness of an input-dependent abstract domain is then guaran- 
teed. The algorithm is therefore formulated as the least fix-point computation 
on a finite abstract domain, so that it terminates. □ 



3.2 Soundness by Domain-Induced Abstract Interpretation 



In this section, we will show how the abstract interpretation <P is obtained as a 
domain-induced abstract interpretation, i.e., an abstract interpretation induced 
from domain abstractions. As a consequence, the soundness proof is given. Note 
that an automatic verification cannot be complete by nature. 

Let the domain and codomain of a function / of type a ^ j3 he and 
respectively. Let the power domain PD[Da] of Da be {cl\j^{X) \ X C £)„} with 
the order C_i = A, where cl\j is the downward closure operator in Da- 




absa ° / 

PD[DaY: 



^ o conc^ 



PD[Da^ 

absi o f-^ 



PDiDp] Predc^ 




PD[Df,\ 



Predp 



abSa o abSa ° / ^ ° conc^ o conc^ 



Fig. 6. Two steps of domain-induced abstract interpretation 



(p (in Fig. 5) is expressed as the two-step domain-induced abstract interpre- 
tation (as indicated in Fig. 6). The first step is backward and consists of 

— the abstract domain PD[Da] 

— the concretization map conCa = ido^ 

— the abstraction map abSa = 

This step precisely detects how much of the input is enough to produce the 
output satisfying the specification. The next step approximates according to the 
specification language in order to make the analysis decidable. Let Preda be a 
set of predicates on Da generated as Pq in Fig. 3. The second step is forward 
and consists of 

— the abstract domain Preda- 

— the concretization map conc^{P) = G Da \ P{x)}) for P G Preda- 
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— the abstraction map abs^{X) = n({P G Preda \ conc^(P) C X}) for X G 
PD[D^\. 

Note that the abstract domain Pred^ is a lattice wrt the entailment relation. 
For instance, PLi Q and P n Q always exists as P /\ Q and P V Q, respectively. 

Thus an abstract interpretation S' on a primitive function op of type a — *■ /3 
is defined by S(op) = abs ■ op~^ ■ cone, where absa = abs^ ■ a6s^ and concp = 
concp ■ conc^. Similar to P on expressions. The abstract interpretation <l> on 
recursively defined functions /i’s is obtained by the least fix-point computation. 

Definition 1. . . , . - <P . - f- f - 

d’if) C abs ■ f~^ ■ cone . . . - . , . . 'P . , . , . . _ 



Theorem 2. . . _ 



. . , , _ , Since the concretization map conca and the abstraction map 

absfs satisfy absa ■ conCa = idua, £^nd conCa ■ absa C cl\j^, a recursively defined 
function is safe. Thus the detected property is sound. □ 

4 Example: Verifying Orderedness of Sorting 

The verification algorithm is explained here by an example of orderedness true 
— > V geq{sort X). When unknown properties of user-defined functions are re- 
quired, new conjectures are produced. For instance, when verifying true — > 
X geq{sort X), it automatically produces and proves the lemmata; 'dleq^ {X) — *■ 
Wleq^{sort X), --null AWleq^{Y) leq^ x \/leq^{max Y), and -^null{Y) 
\/rgGq{niax Y). The generation of lemmata is shown at the top of Fig. 7. The 
vertical wavy arrow indicates an iterative procedure, the double arrow indicates 
the creation of a conjecture, and the arrow returns the resulting lemma. 

For instance, 'ileq^iX') — > yieq^ {sort X) means that if an input of sort is 
.. . any given Z , an output is also .. , , . Z . This 

lemma is generated as a conjecture true — > \/leq^ {sort X) at the else-branch 
of the if-expression in sort ('F|b: : sort bsjV^eg) as follows. 

X geq{b :: sort bs) = \/rgeq{b, sort bs) A X geq{sort bs) 

= yieq^{sort bs) A Xgeq{sort bs) 

Since there are no conjectures related to yieq^ {sort X) in the recursion hypoth- 
esis, a new conjecture is created. But properties of functions {Pp in Fig. 3) ex- 
clude bound variables. Thus, by the /^fyexpansion, \/leq^{sort X) is transformed 
to yieq^ {sort X) with the substitution [Z <— 6], and true ^ yieq^ {sort X) is 
created. This means that no local information on b is used during the verifica- 
tion of true — > yieq^ {sort X). This conjecture does not hold; instead, we obtain 
yieq^{X) — > yieq^ {sort X) as a lemma. 
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true — > ^geq(sort X) 



true — > 'ileq^ {sort X) 

i 

yieq^{X) — > \/leq^ {sort X) 



true — > 'irgeq{max Y) 

i 

-<null{Y) — > 'irgeq{max Y) 

i 



- true — > \/leq^ {sort X) 

true — > leq^ x true(ma2; Y) 
first > 

iteration 

->null{Y) A 'ileq^ — > leq^ x true(maa; Y) 

= 'ileq^ {X) — > {sort X) 

true — > leq^ x 'ileq^ {max Y) 
second > 

iteration 

-inull{Y) /\'ileq^{Y) — )• leq^ x 'ileq^ {max Y) 
VZeg^(X) — » 'ileq^{sort X) {converged) 



Fig. 7 . Generation of lemmata for true Vgeq{sort X) 



A typical example of the use of the entailment relation appears in the ver- 
ification of ^null{Y) \/rg^q(tnax Y). At the second if-expression in max, 
S'|if leq(e,d) then (d,e::es) else (e,d: :es)]Vr-geg is created. Thus, 
{leq{e, d) Xileq'^{es)) V {^leq{e, d) Xileq^{es)) is obtained. From the transitivity 
of leq, leq{e,d) A VZeq'^(es)) G leq{e,d) f\'ileq‘^{es) (see the underlined parts), 
therefore we obtain \/leq^{es) by the ^-elimination. Note that the ^-elimination 
also creates yieq‘^{es), but only yieq^{es) branch is successful, i.e., from the re- 
cursion hypothesis !F|max dsJVr^eq is reduced to ^null{ds), as desired. Thus 
yieq'^{es) is omitted. 

5 Extensions 

5.1 New Predicate Constructors 

In this section we introduce new predicate constructors and extend the entail- 
ment relation to make it possible to verify weak preservation of sort programs. 
The new predicate constructors are 3, 3;, 3^, and A. The predicates are extended 
by updating part of the grammar in Fig. 3 with 

Pr = yPu \ ^Pu I VPg I APg I Pp I Pr a Pr I Pr V Pr properties of lists 
Pp = Pb I Pp I Ps X Ps I VrPs I V;Pb | 3;Pb | d^Pp | properties of pairs 

Pp A Pp I Pp V Pp 

where the underlined parts are newly added. Their meanings are shown by ex- 
amples in the table below. The entailment relation is enriched as in Fig. 8. 



predicate 


. . ^ 


3geq^{as) 


[3,6,4] 


([3,2,4]), 


nil 


3ileq{as, a) 


([3,6,4], 5) 


([3,6,4], 2), 


(nil, 5) 


3rleq(a, as) 


(5, [3,6,4]) 


(7, [3,6,4]), 


(5, nil) 


Aleq(as) 


[3,2,4] 


[3,6,4], [3] 


, nil 
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Then weak preservation of sort is expressed by 

^ 

true ^ \/i3requal A \/r^iequal {sort X). 

^ 

During the verification of true — > ViBrOqual {sort X), the key step is at 
yi3requal{as,b :: sort{bs)) in sort. By transitivity \/i3requal{as,b :: bs) A 
\/i3requal{b :: bs,b :: sort{bs)) is inferred. To solve the second component, the 
entailment relation V;3rP(a :: as,b :: bs) C P{a,b) A V;3rP(as, &s) is used. This 
is obtained as a transitive closure by 

V;3rP(a :: as, b :: bs) = 3rP{a, b :: bs) A V;3rP(as, b :: bs) 

C {P{a,b) V 3rP{a,bs)) A'^i3rP{as,bs) 

C P{a, b) A V;3rP(as, bs). 

Thus \/i3requal{b :: bs,b :: sort{bs)) is reduced to \/i3requal{bs, sort{bs)) which 
is a recursion hypothesis. The rest \/i3requal{as,b :: bs) creates the conjecture 

Y 

true \/i{equal x true V true x 3rcqual) {max Y) 

at (b,bs) = max as, and similar approximations occur in max at expressions 

^ 

(d,e: :es) and (e,d: :es). true ^ 3iire-quo,l {sort X) is similarly verified. 



Pi C P 2 



Pi Q P 2 



list 



APl C AP 2 fPl c ]P2 

3{P = 3rP ^=3iP 

P ^ P^ X P^ 



\/l3rP A {'il3rP)^“ X (Vi3.P)"" 

3P(a :: as) = P{a) V 3P(as) 
3P{nil) = false 



t (Pi V P 2 ) = fPi V fP 2 with t e {3, 3i, 3.} 

(3iP)^ = 3(P®) 3i3,P = 3.3iP 

P (Z X P^ 

Transitivity 



3XrP A (3iV.P)"" X (3iV.P) 

\/{3rP{as,b :: bs) C \/i3rP{as,hs) 
Vr3iP(a :: as,bs) C Vr3iP(as,6s) 
AP{a :: b :: bs) = 3P“(fe :: bs) A {nuU{bs) V AP{b :: bs)) 

AP{a :: nil) = false AP{nil) = false 

Fig. 8. New entailment relation 



5.2 Uninterpreted Functions and Predicates 

This section extends the range of conditional expressions that can be included in 
the programs to be verified. Function symbols (either primitive or user-defined) 
in the conditional part of an if-expression are allowed. They are left uninter- 
preted during the verification, and the result will be refined by partial evaluation 
of these function symbols. 
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The example is a formatting program format that formats a sentence (ex- 
pressed by a list of strings) as a list of sentences each of which has a width 
.. . . a specified number M. Its specifications are as follows. 

— Each sentence of the output must have a width less-than-equal to M. 

— The order of each word in the input must be kept in the output. 

— Each word of the input must appear in the output, and vice versa. 

fun format as = f (as, nil); 

fun f (bs,cs) = if null bs then [cs] else 
let val d: :ds = bs 
in if leq (width (cs@[d]),M) 
then f (ds , cs@ [d] ) ) 
else cs::f (ds,[d]) end; 

fun width es = if null es then 0 else 
let val f::fs=es in 
if null fs then size f 

else 1+size f+width fs end; 

In this example, string is added to base types. Basic functions -I- and con- 
stants 0, 1 also are used in the program, but they are not directly related to the 
verification. Thus, their interpretation and entailment relations are omitted. 

The first specification of format states that an output must satisfy y{leq^ ■ 
width). Note that this predicate allows a function symbol width in it. Verification 
starts with true ^ \/{leq^ ■ width){f ormat X), which is immediately reduced 
to true ^ y{leq^ ■ width){f Y). The result of the verification is 

{yieq^ ■ width • [ ]) x {leq^ ■ width){Y) y{leq^ ■ width){f Y), 

and this deduces 

{yieq^ ■ width ■ [ ])(AT) A {leq^ ■ width){nil) y{leq^ ■ width){f ormat X). 

Note that the result is not affected by whatever width is, since width is left 
uninterpreted. The key steps are at if leq (width (cs@[d]),M) then .... 
Since the throughout of then-branches leq{width {cs@[d\),M) holds, the second 
argument of / {ds, cs@[d]) always satisfies leq^ -width. These steps depend only 
on V-elimination so that the function symbol width remains uninterpreted. 

With the aid of partial evaluation which leads to width nil = 0, width [x] = 
size X, we obtain y{leq^ ■size){X)Aleq{0, M) y {I eq^ -width) {for mat X). For 

the partial evaluation, only the relation between size and width is important. 
The information on the function size is required only when the final result above 
is interpreted by a human being. Note that in general a partial evaluation may 
not terminate. However, this final step is devoted to transforming the detected 
property into a more intuitive form for a human being, and even if it fails the 
detected property is correct. 
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The second and the third specification of format are similar to orderedness 
and weak preservation of sort, respectively. They require further extensions. 
The second specification of f ormat is expressed by a , . . binary predicate 

on pairs of strings as V (X) ^ VV A VD {format X) where □ 
is an abbreviation of VjVr. Note that throughout the verification the predicate 
is left uninterpreted. This implies that the specification above holds for any 
binary relation . Finally, the meaning of is assumed by a human being, 

and in this case it is suitable to be interpreted as the appearance order of strings. 

^ 

The third specification is expressed by true — > {format X) 

^ 

and true — > \/fij3iequal {format X). Our algorithm detects the latter, but 
for the former we also need a new transitivity-like entailment relation of type 
list{a) X list{list{a)), i.e., 

P X 

Wl3r3rP E X 



6 Related Work 

Many studies have been undertaken on verification. Most are based on theorem 
provers, for example, Coq, LCF, Boyer-Moore prover. Larch, and EQP. They 
require either complex heuristics or strong human guidance (or both), either of 
which is not easy to learn. However, for huge, complex, and critical systems, this 
price is worth paying. 

The complementary approach uses intelligent compile-time error detection 
for easy debugging. For imperative programs, Bourdoncle proposed an assertion- 
based debugging called . . , yy- y [5,4]. For logic programs. Comini, et. 

al. [8] and Bueno, et. al. [6] proposed extensions of declarative diagnosis based 
on abstract interpretation. Cortesi, et. al. [10,18] proposed the automatic verifi- 
cation based on abstract interpretation. Levi and Volpe proposed the framework 
based on abstract interpretation to classify various verification methods [20]. 
Among them, target specifications primarily focus on behavior properties, such 
as termination, mutual exclusion of clauses, and size/cardinality relation between 
inputs and outputs. 

In contrast. Metayer’s [19] and our specification language (for functional pro- 
grams) directly express the programmer’s intention in a concise and declarative 
description. This point is more desirable for some situation, such as, when a 
novice programmer writes a relatively small program. 

As an abstract interpretation, our framework is similar to - . , - y 

- [14]. The significant difference is that inverse image analysis deter- 
mines - 

and computes Scott’s , sets. Our framework, in contrast, determines . / 

y . . . . , . - and com- 

putes Scott’s . sets. In terms of [22], the former is expressed by a HOMT 
{id, — , E-O) rain), and the latter is expressed by {id, —, E-i, wax). 

Similar techniques that treat abstract domain construction as a set of pred- 
icates are found in several places. However, predicates are either limited to 
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unary [15,17,3,21] (such as null and ^null), or are limited to propositions cor- 
responding to variables appearing in a (logic) program [9]. 

7 Conclusion 

This paper reconstructs and extends the automatic verification technique of Le 
Metayer [19] based on a backward abstract interpretation. To show the effective- 
ness, two examples of the declarative specifications of the sorting and formatting 
programs are demonstrated. Although we adopted the simple and inefficient sort- 
ing program here, we also tried efficient sort programs, such as orderedness of 
. and y . . (both topdown and bottomup), and weak preservation 

of the - , - / . y ... These verifications are quite messy by hand [23]. 

Future work will include the implementation and the exploration of its use 
on more complex examples. An efficient implementation may require an efficient 
reachability test algorithm (as well as a congruence-closure algorithm) and a 
strategy to prune highly-nondeterministic ^-eliminations and transitivity. 
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Abstract. Needed narrowing is a complete operational principle for 
modern declarative languages which integrate the best features of (lazy) 
functional and logic programming. We define a transformation methodol- 
ogy for functional logic programs based on needed narrowing. We provide 
(strong) correctness results for the transformation system w.r.t. the set 
of computed values and answer substitutions and show that the promi- 
nent properties of needed narrowing -namely, the optimality w.r.t. the 
length of derivations and the number of computed solutions- carry over 
to the transformation process and the transformed programs. We illus- 
trate the power of the system by taking on in our setting two well-known 
transformation strategies {composition and tupling). We also provide an 
implementation of the transformation system which, by means of some 
experimental results, highlights the benefits of our approach. 



1 Introduction 

Functional logic programming languages combine the operational principles of 
the most important declarative programming paradigms, namely functional and 
logic programming (see [14] for a survey). Efficient demand-driven functional 
computations are amalgamated with the flexible use of logical variables provid- 
ing for function inversion and search for solutions. The operational semantics of 
integrated languages is usually based on narrowing, a combination of variable 
instantiation and reduction. The instantiation of variables is often computed by 
unifying a subterm of the goal expression with the left-hand side of some pro- 
gram rule; then narrowing reduces the instantiated goal using that rule. Needed 
narrowing is currently the best narrowing strategy for first-order, lazy functional 
logic programs due to its optimality properties [5]. Needed narrowing provides 
completeness in the sense of logic programming (computation of all solutions) as 
well as functional programming (computation of values), and it can be efficiently 
implemented by pattern matching and unification. 

* This work has been partially supported by CICYT under grant TIC 98-0445-C03-01. 



A. Middeldorp, T. Sato (Eds.): FLOPS’99, LNCS 1722, pp. 147—162, 1999. 
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The fold/unfold transformation approach was first introduced in [8] to opti- 
mize functional programs and then used for logic programs [28]. This approach 
is commonly based on the construction, by means of a . . y . , of a sequence of 

equivalent programs each obtained by the preceding ones using an ... 
transformation rule. The essential rules are , - . y and . , . - y , i.e., contrac- 

tion and expansion of subexpressions of a program using the definitions of this 
program (or of a preceding one). Other rules which have been considered are, 
for example, instantiation, definition introduction/elimination, and abstraction. 

There exists a large class of program optimizations which can be achieved 
by fold/unfold transformations and are not possible by using a fully automatic 
method (such as, e.g., partial evaluation). Typical instances of this class are the 
strategies that perform . , . y (also known as. y ) [8,11], which merges sep- 

arate (nonnested) function calls with some common arguments into a single call 
to a (possibly new) recursive function which returns a tuple of the results of the 
separate calls, thus avoiding either multiple accesses to the same data structures 
or common subcomputations, similarly to the idea of . . - . y which is used in 

graph rewriting to improve the efficiency of computations in time and space [6] . 

A closely related strategy is , , [30] (also known as , , - , . , 

- ,or, _ , , . y [12]), which essentially consists of the merging of nested 

function calls, where the inner function call builds up a composite object which 
is used by the outer call, and composing these two calls into one has the effect 
to avoid the generation of the intermediate data structure. The composition can 
be made automatically [30], whereas tupling has only been automated to some 
extent [9,10]. 

Although a lot of literature has been devoted to proving the correctness of 
fold/unfold systems w.r.t. the various semantics proposed for logic programs 
[7,13,20,21,23,28], in functional programming the problem of correctness has re- 
ceived surprisingly little attention [26,27]. Of the very few studies of correctness 
of fold/unfold transformations in functional programming, the most general and 
recent work is [26], which defines a simple (syntactic) condition for restricting 
general fold/unfold transformations and which can be applied to give correctness 
proofs for several well-known transformation methods, such as the deforestation. 

In [2], we investigated fold/unfold rules in the context of a strict ( 

) functional logic language based on unrestricted (i.e., not optimized) nar- 
rowing. The use of narrowing empowers the fold/unfold system by implicitly 
embedding the instantiation rule (the operation of the Burstall and Darlington 
framework [8] which introduces an instance of an existing equation) into unfold- 
ing by means of unification. However, [2] does not consider a general transfor- 
mation system (only two rules: fold and unfold), and hence the composition or 
tupling transformations cannot be achieved. Also, [2] refers to a notion of “re- 
versible” folding, which is strictly weaker than the one which we consider here. 
On the other hand, the use of unrestricted narrowing to perform unfolding may 
produce an important increase in the number of program rules. 

In this paper we define a transformation methodology for lazy ( , . ) 

functional logic programs. On the theoretical side, we extend the Tamaki and 
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Sato transformation rules [28] for logic programs to cope with lazy functional 
logic programs based on needed narrowing. The transformation process consists 
of applying an arbitrary number of times the basic transformation rules, which 
are: definition introduction, definition elimination, unfolding, folding, and ab- 
straction. Needed narrowing is complete for. . , programs [4]. 

Thus, we demonstrate that such a program structure is preserved through the 
transformation sequence {TZq, . . . , ??.„), which is a key point for proving the cor- 
rectness of the transformation system as well as its effective applicability. For 
instance, by using other variants of narrowing (e.g., lazy narrowing [22]) the 
structure of the original program is not preserved, thus seriously restricting the 
applicability of the resulting system. The major technical result consists of prov- 
ing strong correctness for the transformation system, namely that the values and 
answers computed by needed narrowing in the initial and the final program co- 
incide (for goals constructed using the symbols of the initial program). The 
efficiency improvement of TZn with regard to TZq is not ensured by an arbitrary 
use of the elementary transformation rules but it rather depends on the heuristic 
which is employed. On the practical side, we investigate how the classical and 
powerful transformation methodologies of , . > and , , . _ [24] transfer 

to our framework. We show the advantages of using needed narrowing to achieve 
composition and tupling in an integrated setting, and illustrate the power of our 
transformation system by (automatically) optimizing several significative exam- 
ples using a prototype implementation [1]. 

The structure of the paper is as follows. After recalling some basic definitions 
in the next section, we introduce the basic transformation rules and illustrate 
them by means of several simple examples in Sec. 3. We also state the correctness 
of the transformation system and show some results about the structure of trans- 
formed programs. Section 4 shows how to achieve the (automatic) composition 
and tupling strategies in our framework as well as an experimental evaluation 
of the method on a small set of benchmarks. Section 5 concludes. More details 
and proofs of all technical results can be found in [3] . 

2 Preliminaries 

We assume familiarity with basic notions of term rewriting [6] and functional 
logic programming [14]. We consider a - > S partitioned into a set C of 

. . and a set JF of (defined) ,, _ or , _ . We write c/n gC 

and f jn € J- for n-ary constructor and operation symbols, respectively. There is 
at least one sort Bool containing the 0-ary Boolean constructors true and false. 
The set of. . and ... .. . . with, . , . (e.g., x,y,z) from X are 

denoted by T(CUiF, X) and T(C, X), respectively. The set of variables occurring 
in a term t is denoted by Varit). A term is . . if it does not contain multiple 
occurrences of any variable. We write oif for the . . of objects oi, . . . , o„. 

A . .. is a term of the form /(d„) where f jn ^ T and di,...,dn G 

T{C,X). Note the difference with the usual notion of pattern in functional pro- 
gramming: a constructor term. A term is , _ . . ( . , . . . ) 
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if it has an operation (constructor) symbol at the root. A. . _ p in a term t 
is represented by a sequence of natural numbers {A denotes the empty sequence, 
i.e., the root position). Positions are ordered by the. ordering: p < g, if 
such that p.w = q. Positions p, q are ... - . if neither p < q nor q < p. Given a 
term t, we let Vos{t) and NVVos{t) denote the set of positions and the set of 
non-variable positions of t, respectively. t\p denotes the ... , of t at position 
p, and t[s]p denotes the result of . - y .. , . . , by the term s. 

We denote by {xi ^ . . . ,Xn i— > tn} the . , , . a with a{xi) = ti for 

i = 1, . . . , n (with Xi yf Xj if i yf j), and cf{x) = x for all other variables x. A sub- 
stitution (T is y , . . , . , if cr(a;) is (ground) constructor for all x such 

that (j{x) yf X. The identity substitution is denoted by id. Given a substitution 
9 and a set of variables P C fb, we denote by 9^y the substitution obtained from 
9 by restricting its domain to V. We write 9 = a [V] if 9^y = a^y, and 9 < a [V] 
denotes the existence of a substitution 7 such that 7 o 0 = cr [P]. A . . of 
two terms s and f is a substitution a with a{s) = cr(t). Two substitutions cr and 

a' are . . . (on a set of variables P) iff there exists some a: G P such 

that a(x) and cr'(x) are not unifiable. 

A set of rewrite rules / ^ r such that I ^ X, and Var(r) C Var{l) is called 

a. / y . .- (TRS). The terms / and r are called the . ... 

( . ) and the . y. . . _ . . ( . ) of the rule, respectively. A TRS TZ is left- 

linear if I is linear for all / — > r S 72.. A TRS is constructor based (GB) if each 

Ihs I is a pattern. In the remainder of this paper, a functional logic , y 
is a left-linear GB-TRS. Gonditions in program rules are treated by using the 
predefined functions and, if _then_else, case_of which are reduced by standard 
defining rules [17,22]. Two (possibly renamed) rules I r and V ^ r' _ . .. , if 

there is a non- variable position p G AfW os{l) and a most-general unifier a such 
that <t(/|p) = cr{l'). A left-linear TRS with no overlapping rules is called .. . y 
.A / . . . . is an application of a rewrite rule to a term, i.e., t —>p^R s 

if there exists a position p in t, a rewrite rule R = I —f r and a substitution a 
with t\p = a{l) and s = t[a{r)]p (p and R will often be omitted in the notation 
of a computation step). The instantiated Ihs a{l) is called a ... A term t is 
called a , , , if there is no term s with t s. denotes the transitive 

closure of ^ and — *■* denotes the reflexive and transitive closure of — 

To evaluate terms containing variables, narrowing non-deterministically in- 
stantiates the variables such that a rewrite step is possible. Formally, t t' 

is a . - y - , if p is a non-variable position in t and a{t) ^p,R t' . We 

denote by to tn a sequence of narrowing steps to '^a-i ■ ■ ■ tn with 

a = (T„ o • • • o CTi . Since we are interested in computing , (constructor 

terms) as well as . / (substitutions) in functional logic programming, we 

say that the narrowing derivation t c C/-.. / ct if c 

is a constructor term. The evaluation to (ground) constructor terms (and not to 
arbitrary expressions) is the intended semantics of functional languages and also 
of most functional logic languages. In particular, the equality predicate w used 

in some examples is defined, like in functional languages, as the - 

on terms, i.e., the equation G « t 2 is satisfied if ti and t 2 are reducible to the 
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same ground constructor term. We say that cr is a , , , . . 
for an equation e if there is a narrowing derivation e true. 



Needed Narrowing. A challenge in the design of functional logic languages is 
the definition of a “good” narrowing strategy, i.e., a restriction A on the narrow- 
ing steps issuing from t, without losing completeness. . . > [5] is 

currently the best known narrowing strategy due to its optimality properties. It 
extends the Huet and Levy’s notion of a needed reduction [18]. The definition of 

needed narrowing [5] uses the notion of . . . [4]. Roughly speaking, 

a definitional tree for a function symbol / is a tree whose leaves contain all (and 
only) the rules used to define / and whose inner nodes contain information to 
guide the (optimal) pattern matching during the evaluation of expressions. Each 
inner node contains a pattern and a variable position in this pattern (the. . 

_ , , ) which is further refined in the patterns of its immediate children 

by using different constructor symbols. The pattern of the root node is simply 
/(ayf), where ayf are different variables. A defined function is called- 

if it has a definitional tree. A rewrite system TZ is called- . , _ , 

if all its defined functions are inductively sequential. 

To compute needed narrowing steps for an operation-rooted term t, we take a 
definitional tree V for the root of t and compute X{t, V). Then, for all {p, R, a) G 
t is a . . - y - , . Informally speaking, needed 

narrowing applies a rule, if possible, or checks the subterm corresponding to 
the inductive position of the branch: if it is a variable, it is instantiated to 
the constructor of a child; if it is already a constructor, we proceed with the 
corresponding child; if it is a function, we evaluate it by recursively applying 
needed narrowing (see [5] for a detailed definition) . 

Consider the following set of rules for and 



0 


< 


N 


-> true 


04-N - 


N 


s(M) 




0 


false 


s(M) 4- N - 


-> s(M4-N) 


s(M) 




s(N) - 


M < N 







Then the function A computes the following set for the initial term X ^ X 4- X: 

{(A, 0 < N true, {X 0}), (2, s(M) + N s(M -f N), {X s(M)})} 

This corresponds to the narrowing steps (the subterm evaluated in the next step 
is underlined): 

X X ~\~ X > 0 } true 

s(M) ^ s(M-|- s(M)) 

Needed narrowing is sound and complete for inductively sequential programs. 
Moreover, it is - - , , i-C., given two distinct needed narrowing derivations 

e true and e •^*/ true, we have that a and a' are independent on Var(e). 
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3 The Transformation Rules 

In this section, our aim is to define a set of program transformations which 
is strongly correct, i.e., sound and complete w.r.t. the semantics of computed 
values and answer substitutions. Let us first give the rules for the introduction 
and elimination of function definitions in a similar style to [28], in which the 
set of definitions is partitioned into “old” and “new” ones. In the following, we 
consider a fixed transformation sequence {TZq, . . . , 7?.fc), k > 0. 

Definition 1 (Definition introduction). ^ ^ Ti-k+i , 



■ - Tlk - / -- - -- f(tn) r 

/(Q- - , - Var{f(t^) = Var{r) . 

/ - - - -- TZo,...,TZk /- new 

- . - . . . . r ^ . TZq 



- . f- - new,, _ . . . , . . , . . y- y . 

TZo - - old , , . _ 

The introduction of a new definition is virtually always the first step of a trans- 
formation sequence. Determining which definitions should be introduced is a 
task which falls into the realm of . . y- (see [23] for a survey), which we 
discuss in Sec. 4. 

Definition 2 (Definition elimination). ... Ti-k+i 

-- y - - T^k - .. . f \ Rf ..... f ^ 

TZo - {TZk — R^) 

This rule has been initially proposed with the name of . _ . (for logic pro- 
grams) in [21] and also in [7], where it was called . - _ . . Note that the 

deletion of the rules defining a function / implies that no function calls to / are 
allowed afterwards. However, subsequent transformation steps (in particular, 
folding steps) might introduce those deleted functions in the rhs’s of the rules, 
thus producing inconsistencies in the resulting programs. We avoid this encum- 
brance by the usual requirement [23] not to allow folding steps if a definition 
elimination step has been performed. 

Now we introduce our unfolding rule, which systematizes a fit combination 
of instantiation and classical (functional) unfolding into a single transformation 
rule, thus bearing the capability of narrowing to deal with logical variables. 

Definition 3 (Unfolding). . R = {I ^ r) G TZk -- . 



- - -- -- ... . -y-, y TZk + 1 . 

TZk . . . y i? /. .. {0(Z) ^ r' \r '^e r' . . ... . y . . - TZk} 



Here it is worth noting that the requirement not to unfold a rule whose rhs is 
not operation-rooted can be left aside when functions are . . . . . (which 

is quite usual in typed languages). The following example shows that the above 
requirement cannot be dropped in general. 
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Consider the following programs: 

n={ g(x) ^ s(f(x)) i n' = { g(o)->s(o)i 

[h(s(X))->s(0) J [h(s(X))-^s(0)J 

By a needed narrowing step s(f(X)) s(0) given from the rhs of the 

second rule of TZ, we get (by unfolding) the transformed program TZ' . Now, the 
goal h(g(s(0))) « X has the successful needed narrowing derivation in TZ 

h( g(s(0)) ) « X ^ h(s(f(s(0)))) KiX s(0) « X 

whereas it fails in the transformed program. Essentially, completeness is lost 
because the considered unfolding rule f (0) ^0 defines a function f which is not 
defined. Hence, by unfolding the call f (X) we improperly “compile in” an 
unnecessary restriction in the domain of the function g. 

Now, let us introduce the folding rule, which is a counterpart of the previous 
transformation, i.e., the compression of a piece of code into an equivalent call. 

Definition 4 (Folding). . R = (I ^ r) G TZk -■ . 

_ . R' = {V ^ r') gTZj Q < j <k . .. . . .... 

r\p = 0{r') , p G NVT’os{r) , .... .. . . . 

. - . - - R . . . - 

. . . . - . / -. TZq, . . . , TZk 

R'. . 1 

/ .... TZk-\-i . > TZk . - .... R 

, , l^r[9{l')]p 

Roughly speaking, the folding operation proceeds in a contrary direction to the 
usual reduction steps, that is, reductions are performed against the reverse fold- 
ing rules. Note that the applicability conditions 2 and 3 for the folding rule 
guarantee that “self folding” (i.e., the possibility to unsafely fold a rule by itself 
[23]) is disallowed. There are several points regarding our definition of the folding 
rule which are worth noticing: (i) As a difference w.r.t. the unfolding rule, the 
subterm which is selected for the folding step needs not be a (needed) narrowing 
redex. This generality is not only safe but also helpful as it will become apparent 
in Example 3. (ii) In contrast to [2], the substitution 6 of Def. 4 is not a unifier 
but just a matcher. This is similar to many other folding rules for logic programs, 
which have been defined in a similar “functional style” (see, e.g., [7,20,24,28]). 
(iii) Finally, the - . condition in Def. 1 can now be fully clarified: it 

avoids to consider a rule I — > r, with Var{r) C Var{l), as a folding rule, since it 
might introduce extra variables in the rhs of the resulting rule. 



R. 



^ A definition rule maintains its status only as long as it remains unchanged, i.e., once 
a definition rule is transformed it is not considered a definition rule anymore. 
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Many attempts have been also made to define a folding transformation in 
a (pure) functional context [8,27]. A , . folding for a lazy (higher-order) 

functional language has been presented in [26], which preserves the semantics 
of (ground constructor) values under applicability conditions which are similar 
to ours. However, our correctness results are slightly stronger, since we preserve 
the (non-ground) semantics of computed values and ^ 

As in our definition of folding, a large number of proposals also allow the 
folded and the folding rule to belong to different programs (see, 
e.g., [7,20,23,24,28]), which in general is crucial to achieve an effective opti- 
mization. Some other works in the literature have advocated a different style 
of folding which is [13], i.e., a kind of folding which can always be 

undone by an unfolding step. This greatly simplifies the correctness proofs — 
correctness of folding follows immediately from the correctness of unfolding — , 
but usually require too strong applicability conditions, such as requiring that 
both the folded and the folding rules belong to the same program, which dras- 
tically reduces the power of the transformation. The folding rule proposed in [2] 
for a strict functional logic language is reversible and thus its transformational 
power is very limited. The folding rule introduced in this paper is more powerful 
and the applicability conditions are less restrictive.^ Therefore, its use within 
a transformation system — when guided by appropriate strategies — is able to 
produce more effective optimizations for (lazy) functional logic programs. 

The set of rules presented so far constitutes the kernel of our transformation 

system. These rules suffice for automatizing the , strategy. However, 

the transformation system must be empowered for achieving the , - y opti- 
mization, which we attain by extending the transformation system with a rule 

of abstraction [8,26] (often known as / . , . rule [24]). It essentially 

consists of replacing the occurrences of some expression e in the rhs of a rule R 
by a fresh variable z, adding the “local declaration” z = e within a where expres- 
sion in R. For instance, the rule double_sum(X, Y) ^ sum(sum(X, Y), sum(X, Y)) 
can be transformed into the new rule 



double_sum(X, Y) sum(Z, Z) where Z = sum(X,Y) . 

As noted by [24], the use of the where-abstraction rule has the advantage that 
in the call-by-value mode of execution, the evaluation of the expression e is 
performed only once. This is also true in a lazy context under an implementation 
based on . . - / , which allows us to keep track of variables which occur several 

times in the expression to be evaluated. 

The new rules introduced by the where-abstraction do contain extra variables 
in the right-hand sides. However, as noted in [26], this can be easily amended by 
using standard “lambda lifting” techniques (which can be thought of as an appro- 
priate application of a definition introduction step followed by a folding step) . For 



^ It would be interesting to study a generalization of our folding rule to a disjunctive 
folding rule, i.e., allowing the folding of multiple recursive rules (see [25]). 
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instance, if we consider again the rule double_sum(X, Y) — > sum(Z, Z) where Z = 
sum(X, Y), we can transform it (by lambda lifting [19]) into the new pair of rules 

double_sum(X, Y) — > ds_aux(sum(X, Y)) 
ds_aux(Z) — !■ sum(Z, Z) 

Note that these rules can be directly generated from the initial definition by a 
definition introduction (ds_aux(Z) ^ sum(Z, Z)) and then by folding the original 
rule at the expression sum(sum(X, Y), sum(X, Y)) using as folding rule the newly 
generated definition for ds_aux/l. The inclusion of an abstraction rule is tra- 
ditional in functional fold/unfold frameworks [8,24,26,27]. In the case of logic 
programs, abstraction is only possible by means of the so called y . . _ 
strategy [24], which generalizes some calls to eliminate the mismatches that pre- 
vent a folding step. 

Now, we are ready to formalize our abstraction rule, which is inspired by 
the standard lambda lifting transformation of functional programs. By means 
of the tuple constructor ( ), our definition allows the abstraction of different 
expressions in one go. For a sequence of (pairwise disjoint) positions P = pif, 
we let t[s^]p = (((t[si]pj[s 2 ]p 2 ) • ■ • [sn]p„)- By abuse, we denote t[^]p by t[s]p 
when Si = . . . = = s, as well as ((t[si]pi) . . ■ [sn]p„) by t[s^]p^. 

Definition 5 (Abstraction). . R = (f{tn) ^ r) G TZk 

y - NVVos{r) . ... r\p = 6i,. 

i = 1, . ■ ■ , j - r = r\e]]-p- TZk+i . Pk 

R^--- {f{t^ ^ f-aux{^,{ei,...,ej)), f.aux{^,{zi,...,Zj)) 

^ . Tj . . . . , ... . _ , . tn f-aux . . y . . y , . 

- (7^o, . . . ,7^fc) . Var{r[zj]p-) = 

Informally, the two rules generated by the abstraction transformation can be 
understood as a syntactic variant of the following rule: 

/(Q ^ rlzjjp- where {zi,...,Zj) = {ei,...,ej) . 

Now we state the main theoretical results for the basic transformations intro- 
duced in this section. We state the correctness of transformation sequences con- 
structed from an inductively sequential program by applying the following rules: 
definition introduction, definition elimination, unfolding, folding, and abstrac- 
tion. In proving this, we assume that no folding step is applied after a definition 
elimination, which guarantees that no function call to a previously deleted func- 
tion is introduced along a transformation sequence [23]. First, we state that 
transformations preserve the inductively sequential structure of programs. 



Theorem 1. . {TZq, . . . ,TZn) . - - . P-o - - - 

... Pi - . . - - y * = !,.. .,n 



Sands formalizes a syntactic - theory [26] which restricts general 

fold/unfold transformations and can be applied to give correctness proofs for 
some existing transformation methods (such as deforestation [30]). However, we 



- P, 

P-- Pi 
A^]p-} 
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find it more convenient to stick to the logic programming methods for proving 
correctness because the narrowing mechanism can be properly seen as a gen- 
eralization of the SLD-resolution method which implicitly applies instantiation 
before replacing a call by the corresponding instance of the body. That is, instan- 
tiation is computed in a systematic way by the needed narrowing mechanism (as 
in the unfolding of logic programs), whereas it is not restricted in the Burstall 
and Darlington’s fold/unfold framework considered in [26]. Unrestricted instan- 
tiation is problematic since it does not even preserve local equivalence, and for 
this reason the instantiation rule is not considered explicitly in [26]. As a conse- 
quence, the improvement theorem of [26] does not directly apply to our context. 

Our demonstration technique for the correctness result is inspired by the orig- 
inal proof scheme of Tamaki and Sato [28] concerning the least Herbrand model 
semantics of logic programs (and the subsequent extension of Kawamura and 
Kanamori [20] for the semantics of computed answers). Intuitively, a fold/unfold 
transformation system is correct if there are “at least as many folds as there 
are unfolds” or, equivalently, if “going backward in the computation (as fold- 
ing does) does not prevail over going forward in the computation (as unfolding 
does)” [23,26]. This essentially means that there must be a kind of “compu- 
tational cost” measure which is not increased either by folding or by unfolding 
steps. Several definitions for this measure can be found in the literature: the 

in [28] , the - in [20] , or the notion of- 

in [26]. In our context, we have introduced the notion of . , . in order 

to measure the computational cost of a given term. The detailed proof scheme 
can be found in [3]. The strong correctness of the transformation is stated as 
follows. 

Theorem 2. . (7?.o, . . . , 7?.„) n > 0 . . .e, 

, - . y / , - - - U U Var(e) ... . , . . 

C'^^true. TZq- e'^*, true. TZn /--- a' = a [V] . , . . y 

4 Some Experiments 

The building blocks of strategic program optimizations are transformation tac- 
tics ( . . y. ), which are used to guide the process and effect some particular 

kind of change to the program undergoing transformation [12,24]. 

One of the most relevant quests in applying a transformation strategy is the 
introduction of new functions, often called in the literature , definitions. 
Although there is no general theory of strategies which ensures that derived 
programs are more efficient than the initial ones, some partial results exist. 
For instance, in the setting of higher-order (non-strict) functional languages. 
Sands [26] has recently introduced the theory of. , .to provide a syn- 

tactic method for guiding and constraining the unfold/fold method in [8] so that 
total correctness and performance improvement are always guaranteed. 

In the following, we illustrate the power of our transformation system by 
tackling some representative examples regarding the optimizations of composi- 
tion [30] and tupling [8,11]. 
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4.1 Transformation Strategies 

The composition strategy was originally introduced in [8,11] for the optimization 
of pure functional programs. Variants of this composition strategy are the. . 

- - . _ . technique [27] and the _ , . . _ . method [30] . By using the 

composition strategy (or its variants), one may avoid the construction of inter- 
mediate data structures that are produced by some function g and consumed as 
inputs by another function f . In some cases, most of the efficiency improvement 
of the composition strategy can be simply obtained by lazy evaluation [12]. Nev- 
ertheless, the composition strategy often allows the derivation of programs with 
improved performance also in the context of lazy evaluation [29] . Laziness is de- 
cisive when, given a nested function call f (g(X)), the intermediate data structure 
produced by g is infinite but the function f can produce its outcome by knowing 
only a finite portion of the output of g. The following example illustrates the 
advantages of our transformation rules w.r.t. those of [2]. 

The function sum_prefix(X,Y) defined in the following program 7?.o 
returns the sum of the Y consecutive natural numbers, starting from X: 

sum_pref ix(X, Y) — s- suml(f rom(X), Y) (i?i) from(X) — > [Xjfrom(s(X))] {R4) 

suml(L, 0) 0 {R2) 0 + X-^X {R5) 

suml([H]T],s(X)) H-k suml(T,X) {R3) s(X) -k Y ^ s(X -k Y) (i?g) 

We can improve the efficiency of TZq by avoiding the creation and subsequent 
use of the intermediate, partial list generated by the call to the function from: 

1. Definition introduction: 

aux(X, Y) ^ suml(from(X), Y) (R?) 

2. Unfolding of rule R 7 (note that instantiation is automatic): 

aux(X, 0 ) — > 0 (i?g) 

aux(X, s(Y)) — > suml([Xjfrom(s(X))], s(Y)) {R9) 

3. Unfolding of rule Rg (note that this is infeasible with an eager strategy): 

aux(X, s(Y)) — > X -k suml(f rom(s(X)), Y) (Rio) 

4. Folding of suml(f rom(s(X)), Y) in rule Rio using Ry: 

aux(X, s(Y)) X - k aux(s(X), Y) (^11) 

5. Folding of the rhs of rule Ri using Rj: 

sum_pref ix(X, Y) — > aux(X, Y) (^12) 

Then, the transformed program TZ^ is formed by the following rules: 



sum_pref ix(X, Y) - 


aux(X, Y) 


(^12) 


aux(X, 0 ) - 


-> 0 


(Rs) 


aux(X, s(Y)) - 


X-k aux(s(X),Y) 


{Rii) 



(together with the initial definitions for -k, from, and suml). 
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Note that the use of needed narrowing as a basis for our unfolding rule is essential 
in the above example. It ensures that no redundant rules are produced by unfold- 
ing and it also allows the transformation even in the presence of nonterminating 
functions (as opposed to [ 2 ]). 

The tupling strategy was introduced in [8,11] to optimize functional pro- 
grams. The tupling strategy is very effective when several functions require the 
computation of the same subexpression, in which case we tuple together those 
functions. By avoiding either multiple accesses to data structures or common 
subcomputations one often gets linear recursive programs (i.e., programs whose 
rhs’s have at most one recursive call) from nonlinear recursive programs [24]. 
The following well-known example illustrates the tupling strategy. 

The fibonacci numbers can be computed by the program TZq: 

fib(O) — > s(0) (i?i) 

fib(s(0)) -> s(0) (i? 2 ) 

fib(s(s(X))) ^ f ib(s(X)) + f ib(X) (i? 3 ) 

(together with the rules for addition -b). Observe that this program has an 
exponential complexity, which can be reduced to a linear one by applying the 
tupling strategy as follows: 

1. Definition introduction: 

new(X) — > (f ib(s(X)), f ib(X)) (-R 4 ) 

2. Unfolding of rule R 4 (narrowing the needed redex fib(s(X))): 

new(O) ^ (s(0),fib(s(0))) (i?s) 

new(s(X)) ^ (fib(s(X)) -b f ib(X), f ib(s(X))) (Rq) 

3. Unfolding of rule (narrowing the needed redex fib(s(0))): 

new(O) (s(0),s(0)) (i?r) 

4. Abstraction of Rq: 

new(s(X)) ^ new_aux((f ib(s(X)), f ib(X))) (Rs) 
new_aux((Zi, Z 2 )) ^ (Zi -b Z 2 , Zi) (-R 9 ) 

5. Folding of (f ib(s(X)), f ib(X)) in rule i?g using R 4 : 

new(s(X)) — > new_aux(new(X)) (.Rio) 

6 . Abstraction of R 3 : 

fib(s(s(X))) — > f ib_aux((f ib(s(X)), f ib(X))) (Rii) 

fib_aux((Zi,Z 2 )) ^ Zi-bZ 2 (R 12 ) 

7. Folding of (f ib(s(X)), f ib(X)) in rule Rn using again rule R 4 : 

fib(s(s(X))) ^ f ib_aux(new(X)) (Ris) 
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Now, the (enhanced) transformed program (with linear complexity thanks 
to the use of the recursive function new), is the following: 



fib(O) — > s( 0 ) (i?i) 

fib(s( 0 )) -> s( 0 ) (i?2) 

f ib(s(s(X))) — > Zi + Z2 where (Zi, Z2) = new(X) (i?i2, i?i3) 

new(O) ^ (s( 0 ),s( 0 )) (i?r) 

new(s(X)) — > (Zi + Z2,Zi) where (Zi,Z2) = new(X) (i?g,i?io) 



where rules (i?i 2 ,^i 3 ) and (i?g,i?io) are expressed by using local declarations 
for readability. 

4.2 Benchmarks 

The basic rules presented so far have been implemented by a prototype system 
Synth [ 1 ], which is publicly available at http : //www . dsic .upv . es/users/ elp/ 
soft.html. It is written in SICStus Prolog and includes a parser for the lan- 
guage Curry, a modern multiparadigm declarative language based on needed 
narrowing which is intended to become a standard in the functional logic com- 
munity [16,17]. It also includes a fully automatic composition strategy based on 
some (apparently reasonable) heuristics. The transformation system allows us 
to choose between two ways to apply the composition strategy. The first way 
is semi-automatic, since the user has to indicate the rule in which a nested call 
appears. A second way is completely automatic. It is the transformer which looks 
for a nested call in one of the rules and introduces a definition rule for a new 
function to start the process. We are currently extending the system in order to 
mechanize tripling (e.g., by using the analysis method of [9]). 

Table 1 summarizes our benchmark results. The first two columns measure 
the number of rewrite rules {Rw\) and the absolute runtimes {RTi) for the orig- 
inal programs. The next column (Comp) shows the execution times of the (au- 
tomatic) composition algorithm. The other columns show the number of rewrite 
rules (RW 2 ), the absolute runtimes (RT 2 ), and the speedups achieved for the 
transformed programs. All the programs have been executed by using Taste- 
Curry, which is a publicly available interpreter for a subset of Curry [16]. Times 
are expressed in seconds and are the average of 10 executions. We note that our 
(automatic) composition strategy performs well w.r.t. the first four benchmarks. 
They are classical examples in which composition is able to perform an effec- 
tive optimization (sumprefix is described in Example 3, while doubleappend, 
lengthapp, and doubleflip are typical functional programs to illustrate de- 
forestation [30]). Regarding the last benchmark fibprefix, which is similar to 
sumprefix but it sums Fibonacci numbers instead of natural numbers, a slow- 
down has been produced (due to an incorrect folding, which added a new function 
call to the recursion). In this case a tupling strategy is mandatory to succeed, 
as expected. 

In general, the transformed programs cannot be guaranteed to be faster than 
the original ones, since there is a trade-off between the smaller amount of compu- 
tation needed after the transformation (when guided by appropriate strategies) 



160 



Maria Alpuente et al. 



Table 1. Benchmark results. 



Benchmarks 


Rwi 


RTi 


Comp 


RW2 


RT2 


Speedup (%) 


doubleappend 


3 


1.77 


0.1 


6 


1.63 


10% 


sumpref ix 


8 


3.59 


0.21 


10 


3.48 


3% 


lengthapp 


7 


1.61 


0.17 


10 


1.51 


6% 


doubleflip 


3 


0.95 


0.11 


5 


0.7 


26% 


f ibpref ix 


11 


2.2 


0.28 


13 


2.26 


-3% 



and the larger number of derived rules. Nevertheless, our experiments seem to 
substantiate that the smaller computations make up for the overhead of checking 
the applicability of the larger number of rules in the derived programs. 

5 Conclusions 

The definition of a fold/unfold framework for the optimization of functional 
logic programs was an open problem marked in [24] as pending research. We 
have presented a transformation methodology for lazy functional logic programs 
preserving the semantics of both values and answers computed by an efficient 
(currently the best) operational mechanism. For proving correctness, we exten- 
sively exploit the existing results from Huet and Levy’s theory of needed reduc- 
tions [18] and the wide literature about completeness of needed narrowing [.5] 
(rather than striving an ad-hoc proof). We have shown that the transformation 
process keeps the inductively sequential structure of programs. We have also 
illustrated with several examples that the transformation process can be guided 
by appropriate strategies which lead to effective improvements. Our experiments 
show that our transformation framework combines in a useful and effective way 
the systematic instantiation of calls during unfolding (by virtue of the logic com- 
ponent of the needed narrowing mechanism) with the power of the abstraction 
transformations (thanks to the functional dimension). We have also presented 
an implementation which allows us to perform automatically the composition 
strategy as well as to perform all basic transformations in a semi-automatized 
way. The multi-paradigm language Curry [15,17] is an extension of Haskell with 
features for logic and concurrent programming. The results in this paper can be 
applied to optimize a large class of kernel (i.e., non concurrent) Curry programs. 
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Abstract. Tabled logic programming is receiving increasing attention 
in the Logic Programming community. It avoids many of the shortco- 
mings of SLD(NF) execution and provides a more flexible and efficient 
execution mechanism for logic programs. In particular, tabled execution 
of logic programs terminates more often than execution based on SLD- 
resolution. One of the few approaches studying termination of tabled 
logic programs was developed by Decorte et al. They present necessary 
and sufficient conditions for two notions of universal termination under 
SLG-resolution, the resolution principle of tabling: quasi-termination and 
(the stronger notion of) LG-termination. Starting from these necessary 
and sufficient conditions, we introduce sufficient conditions which are 
stated fully at the clause level and are easy to automatize. To this end, 
we use mode and type information: we consider simply moded, well-typed 
programs and queries. We point out how our termination conditions can 
be automatized, by extending the recently developed constraint-based 
automatic termination analysis for SLD-resolution by Decorte and De 
Schreye. 



1 Introduction 

Tabled logic programming [5,14], extending standard SLD-resolution with a 
tabling mechanism, avoids many of the shortcomings of SLD execution and pro- 
vides a more flexible and often considerably more efficient execution mechanism 
for logic programs. In particular, tabled execution of logic programs terminates 
more often than execution based on SLD. So, if a program can be proven to termi- 
nate under SLD-resolution (by one of the existing automated techniques surveyed 
in [6]), then the program will trivially also terminate under SLG-resolution, the 
resolution principle of tabling [5]. However, since there are programs and queries 
which terminate under SLG-resolution and not under SLD-resolution, more ef- 
fective proof techniques can be found. One of the few works studying termination 
of tabled logic programs is [7], in which necessary and sufficient conditions are 
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given for two notions of universal termination under LG-resolution, i.e. SLG- 
resolution with left-to-right selection rule: namely quasi-termination and (the 
stronger notion of) LG-termination. 

This work is based on [7]. Starting from the necessary and sufficient con- 
ditions of [7], we present sufficient conditions for quasi-termination and LG- 
termination which are stated fully at the clause level. To this end we use mode 
and type information: we consider simply moded, well-typed programs and 
queries. Our termination conditions are easy to automatize. In particular, we 
show how the framework of [8], where a constraint-based automatic termina- 
tion analysis for LD-resolution (SLD-resolution with left-to-right selection rule) 
is given, needs to be modified in order to prove quasi-termination and LG- 
termination in an automatic way. 

In the following Section 2 of preliminaries, we first recall the notion of SLG- 
resolution [5] for definite programs. Next, we define the notions of simply mo- 
dedness, well-typedness and input safe atoms and we give some definitions and 
properties of norms and level mappings. In the following Section 3, the notion 
of quasi-termination and its characterisation of [7], namely quasi-acceptability, 
are introduced. We present an easy to automatize, sufficient condition for quasi- 
termination of simply moded well- typed programs and queries in Subsection 3.1. 
We point out in Subsection 3.2 how this condition can be automatized, by ex- 
tending the automatic, constraint-based termination analysis for LD-resolution 
of [8]. By the lack of space, we do not consider the stronger notion of LG- 
termination in this paper. Instead, we refer to the full version of the paper, [15], 
where we present an optimatization of the necessary and sufficient condition 
of [7] for LG-termination, together with an easy to automatize condition for 
LG-termination of simply moded well- typed programs and queries. We want to 
note however that this automatizable condition for LG-termination is obtained 
from its characterisation in a similar way as the one for quasi-termination. In 
Section 4 we conclude this paper with a discussion on related works. We refer 
to the full version of the paper, [15], for more examples and all the proofs. 

2 Preliminaries 

We refer to [12] for the basic concepts of logic programming. Throughout the 
paper, P will denote a definite logic program. The .... . . - . , 

Up, and the ... , . , Bp, associated with a program P are 

defined as follows. Let Termp and Atomp denote the set of respectively all 
terms and atoms that can be constructed from the alphabet underlying P. The 
variant relation, denoted w, defines an equivalence. Up and Bp are respectively 
the quotient sets Termp/ w and Atomp/ For any term t (or atom A), we 
denote its class in Up (Bp) as t (A). However, when no confusion is possible, 
we omit the tildes. We use the abbreviation mgu for most general unifier. 

We will refer to SLD-derivations following the left-to-right selection rule 
as LD-derivations. Other concepts will adopt this naming accordingly. Given 
S C Bp, by Call(P,S) we denote the subset of Bp such that B € Call(P,S) 
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whenever an element of i? is a selected literal in an LD-derivation for some 
PU{<— A\, with A£ S. Throughout the paper we assume that in any derivation 
of a query w.r.t. a program, representatives of equivalence classes are systema- 
tically provided with fresh variables, to avoid the necessity of renaming apart. 

2.1 SLG-Resolution for Definite Programs 

The ideas underlying tabling are very simple. Essentially, under a tabled execu- 
tion mechanism, answers for selected atoms are stored in a table. When a variant 
of such an atom is recursively called, the selected atom is not resolved against 
program clauses, instead, all corresponding answers computed so far are looked 
up in the table and the corresponding answer substitutions are applied to the 
atom. This process is repeated for all subsequent computed answer substitutions 
that correspond to the atom. 

We present a non-constructive definition of SLG-resolution, the resolution 
principle underlying tabling, and refer to [5,14] for more constructive formula- 
tions of (variants) of tabled resolution. 

Definition! (pseudo SLG-tree, pseudo LG-tree). .P .. 

y TZ _ . . - A _ pseudo SLG-tree for P U {<— A} 

under TZ. . ta .... 

- . TA . y y- .. - - _ , 

. . . .. y . TZ 

. , ta- - ^ A 

y . P .. - / , - y y - 



Be 



... TZ 

. p 



e 




, TZ. .. Ta. - pseudo LG-tree , PU{^ A} 

... . . . ta. PU{^ y4}. smaller.. .. ... 

t'a. P U A} . . ... _ , , TA y / 

ta 

(computed) answer clause . , . .. . ta.- PU{<— A}. 

y - y A9 ^ e. , .. 

. . ta ^ - y - - - . . 

Intuitively, a pseudo SLG-tree (in an SLG-forest, see Definition 2 below) 
represents the tabled computation of all answers for a given subquery labeling 
the root node of the tree. The trees in the above definition are called . ... 

SLG-trees because there is no condition yet on which clauses B9 <— exactly are 
to be used for resolution in point 4. These clauses represent the answers found 
(possibly in another tree of the forest) for the selected atom. This interaction 
between the trees in an SLG-forest is captured in the following definition. 
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Definition 2 (SLG-forest, LG-forest). . P , .. y TZ . 

- - T . . , ^ 

.... T . . . , . .. P. SLG-forest for P and T 

under TZ. T. .... ... . {ta \ A G T} / . 

ta. - . - - - y- L'U A} - TZ 

B , ..... Ta G P . . . , 

. B' , T . .. . . ^... B. . . y 

' . ’’'b' - - - ' - -- 

- . y y y .. . - ^. .. B 

. S . . y . , SLG-forest for P and S under TZ. , . , 

. T,... S<ZT , S={A} , . y . 

y PU{^ A} LG-forest- y . 

Point 2 of Definition 2, together with the imposed minimality of trees in 
a forest, now uniquely determines these trees. So we can drop the designation 
“pseudo” and refer to (S)LG-trees in an (S)LG-forest. 

Let be the following program defining the natural numbers: 

f nat{0) ^ 
nat{s{X)) <— nat{X) 

Let S = {nat{X)}. Then the (unique) (S)LG-forest for P and S, shown in Fig. 1, 
consists of a single (S)LG-tree. Note that this tree is infinitely branching. 




Fig. 1. The SLG-forest for NAT U {<— nat{X)}. 



We want to note that we can use the notions of LD-derivation and LD- 
computation (as they appear in the definition of the call set Call{P, S)) even in 
the context of SLG-resolution, as the set of call patterns and the set of computed 
answer substitutions are not influenced by tabling; see e.g. [11, Theorem 2.1]. 

2.2 Simply Modedness, Well-Typedness and Input Safe Atoms 

Definition 3 (mode for a predicate). . p , n 

mode y p. y, - nip : {1, . . . , n} — > {In, Out} , nip{i) = In 
Out .. / input output position . y p / . m,p 
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We assume that each predicate symbol has a unique mode. Multiple modes 
can be obtained by simply renaming the predicates. To simplify the notation, 
when writing an atom as p(u, v) we assume that u is the sequence of terms filling 
in the input positions of p and v is the sequence of terms filling in the output 
positions of p. For a term t, we denote by V ar{t) the set of variables occurring 
in t. Similar notation is used for sequences of terms. 

We introduce the notion of simply modedness [2] . A family of terms is called 
if every variable occurs at most once in it. 

Definition 4 (simply modedness). Po(so,tn+i) 

Tn(sn,tn)- - simpfy moded. .. , . 

. yar(ti) n (U*^QFar(sj)) = 0 

y , - . simply moded- , - 

^ Ti(si,ti), . . . ,p„(s„,t„). simpfy moded., .. 

• ' • 1 Tn(Sn; tn) - - , - - / - p~ 

For instance, with moding q{In, Out), the clause q{f{X), f{Y)) ^ q{X, Y) is 
simpfy moded, but the clause q{X, Y) ^ q{X, f{Y)) is not. The notion of simpfy 
modedness is persistent [2], that is: . , . 

... .... . , .. - . . / An 

atom is called- , , . . . if the family of terms occurring in its input 

positions has no variable in common with the family of terms occurring in its 
output positions. As a corollary to the persistence of the notion of simpfy mo- 
dedness, we have that: P . . , , . , 

Q . .. - , PU{^Q} . .. . ., . .. . . 

- - ^ ^ -In [2], 

it is argued that most programs are simpfy moded, and that often non-simply 
moded programs can be naturally transformed into simpfy moded ones. 

We next introduce the notion of input-correct atom w.r.t. a set of atoms. 
This notion will be useful in our termination condition. 

Definition 5 (input-correct atom w.r.t. S). -SC Bp . A = p(u, v) 

A input-correct w.r.t. S' .... . € S^" ... . 

B = p(u, w) ... . B G S 

In the sequel, we also use types. A . . . is defined as a decidable set of terms 
closed under substitution. A type T is called ^ ... if all its elements are ground, 

and y , . otherwise. A . . . . . , is a construct of the form s : S, where s 

is a term and S is a type. Given a sequence s : S = si : Si, . . . , s„ : S„ of typed 
terms, we write s S S iff for every i G [1, n], we have Si G Si. 

Some examples of types are: U , the set of all terms; Ground, the set of 
all ground terms; List, the set of all (possibly non-ground) nil-terminated lists 
(built on the empty list [ ] and the list constructor [.|.]); and , the set of all 
natural numbers {0, s(0), s(s(0)), . . .}. Throughout the paper, we fix a specific 
set of types, denoted by Types. We also associate types with predicates. 

Definition 6 (type for a predicate, correctly typed). . p , n 

... type,, p. ,, . - . tp : {1,. .. ,n} ^ Types , tp{i) = T 



pi(si,ti), . . . , 



P ^Pi(si,ti), 
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^ T .. type associated with position i of p 

- . tp , .. . . p y . .. . . , p(si,...,s„). 

correctly typed in position i. Si G tp{i) p(si, • ■ ■ , Sn)- correctly 

typed. . - 

When every considered predicate has a mode and a type associated with 
it, we can talk about types of input positions and of output positions of an 
atom. An n-ary predicate p with a mode nip and type tp will be denoted by 
p{< nip{l) : tp{l) mp{n) : tp{n) >). To simplify the notation, when 

writing an atom as p(u : S,v : T) we assume that u : S is a sequence of typed 
terms filling in the input positions of p and v : T is a sequence of typed terms 
filling in the output positions of p. We call p(u : S, v : T) a . ... . 

Next, we introduce the notion of well-typedness [4]. First, we need the fol- 
lowing concept of a type judgement. 

Definition 7 ((true) type judgement). . . . , , s : S 

t : T. . type judgement > . s : S ^ t : T. true ... 

h=s:S=^t:T. , 0 s0 S S. . t6l S T 

Definition 8 (well-typedness). 

Po(^0 ■ OoAn+l ■ In+l) ^ Pl(ll ■ IljOl ■ Ol); Pn(ln ■ In;On ■ ^n) 
. well-typed. , jG[l,n + l] ^ Oq : Oo, • ■ • , Oj_i : Oj_i ij : Ij 
y .. . well-typed. / ... 

- ^Pi(ii:Ii,Oi: Oi),...,pn(i„:l„,o„: On), well-typed., .. 

P ^ Pl(ll ■ Ol)i Pn (in-IniOn-On)- / - V ~ 



Note that in a well-typed query, the left-most atom is correctly typed in 
its input positions. We want to note that the notion of/ ... [1], is 

a special case of the notion of well-typedness. Namely, the definition of well- 
modedness is an instance of Definition 8, where the types of all positions are 
(implicitly) defined as Ground (see [1, Theorem 3.7] for more details). Hence, 
the results in this paper obtained for well-typed programs and queries, also hold 
for well-moded programs and queries. 

As for simply modedness, the notion of well-typedness is persistent [4], that 

is: - . . - . / / . - . . . 

.. . . / / ... . . Hence, we have that: / . - , P 

- / ^ . Q - . - . . - . , PU{^ Q} 

In [2] the notion of generic expression for a type was introduced. Intuitively, a 
term f is a generic expression for a type T if it is more general than all elements 
of T which unify with t. This notion is the main tool in the approach of [2] 
towards replacing unification by iterated matching. It turns out that surprisingly 
often the input positions of the heads of program clauses are filled in by generic 
expressions for appropriate types (see [2]). We recall the definition. 
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Definition 9 (generic expression for a type). . T , . . t. 

generic expression for T. , - s€T. . , t s . . . 

/. .. f .. s. . . , t 

For example, [ ], [AT], [XjF], [X, Y\Z], . . . are generic expressions for the type 
List] 0, s(X), s(s(s(X))), . . . are generic expressions for the type . A term 
of the form f{Xi , . . . , Xm) with Xi, . . . , Xm a sequence of different variables 
is called a. - , ... In [2, Lemma 3.7], it was shown that: variables 

are generic expressions for any type; the only generic expressions for type U are 
variables; if the type T does not contain variables, then every pure variable term 
is a generic expression for T; and if T is - , then every term is a generic 

expression for T. In [2], the notion of input safe atom was introduced as follows. 

Definition 10 (input safe atom). . . input safe., . , 



In particular, an atom is input safe if the types of all input positions are 
ground. The notion of input safe atom is interesting for the following reason. 
The parameter passing mechanism in the unification of a simply moded query 
A, which is correctly typed in its input positions, with an input safe head atom 
H is as follows: first the input values are passed from the atom A to the head H, 
then the output values are passed from H to A. The next proposition generalizes 
this informal argument (we refer to [15] for more details). In the sequel, we 
abbreviate simply moded well- typed with SMWT. 

Proposition 1. 

, a = e^...9^. 

. P .. .. . 

It follows from Proposition 1 that, if P and <— A are SMWT and if the heads 
of the clauses in P are input safe, then in every LD-derivation of PU A} the 
input arguments of A get never instantiated. We will use this in the termination 
condition for SMWT programs and queries (Theorem 2). Namely, if the heads 
of the clauses of the program are input safe, we are no longer forced to reason on 
“calls” in the termination condition, instead, the termination condition can be 
easily stated at the clause level, which is useful in the context of an automatic 
termination analysis. 

In [2] it was shown that if a program P and query ^ A are SMWT and 
if the heads of the clauses in P are input safe, P U A} is unification free 
(i.e. unification can be replaced by iterated matching). We refer to the list of 
program examples in the discussion section of [2], where appropriate modings 
and typings for the considered predicates are given such that the programs are 
SMWT and the heads of their clauses are input safe. Note that for surprisingly 
many programs appropriate modings and typings can be found. 



P 



Pi 



■ , Bn 



P 



Pi 



Bl, , Bn 

■ . Bia 
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2.3 Norms and Level Mappings 

We recall the definitions of norm and level mapping. 

Definition 11 (norm, level mapping). .P y norm 

. ,, - II . II : t/f ^ IN level mapping. . , , _ . |.| : ^ IN 

We introduce some notation. By Predp, Funp, Constp and Varp we de- 
note the sets of predicate, function, constant symbols and variables of P respec- 
tively. The set of, , PC{P), respectively,, . - - , 

FC{P), associated to a program P are the sets of symbols PC{P) = {pi \ p/n £ 
Predp Ai £ {1, . . . , n}}, and FC{P) = {fi \ f /m £ Funp Ai £ {0, 1, . . . , rn}}. 
Here, all norms and level mappings will be of a specified form (for the norms 
this is a slight variant of the semi-linear norms [3]). 

Definition 12 (symbolic norm and level mapping, symbol mapping). 

symbolic norm || . ||'^ - symbolic level mapping |.|‘^ , , 

f II X 11'^ = II c 11'^ = 0 , X £ Varp, c £ Constp, 

\ii f = /o+e::i/.ii f 

\p{tl,...,tn)f =Y.7=lPi\\ 11^ 

h£FC{P) . i€{0,...,m} _ p, €PC(P) , i£{l,...,n} 

symbol mapping. , , . y s : FC{P) U PC{P) IN 

A symbol mapping s induces in a natural way a norm and a level mapping, 
by mapping the coefficient symbols in the symbolic norm and level mapping 
to their actual values under s. The norm, resp. level mapping, induced by the 
symbol mapping s is denoted by || . ||^, resp. |.|g. For example, the . 

is induced by the symbol mapping s with s(/i) = 1, i = 0,...,n, for all 
f /n £ Funp. 

Next, we define the notion of finitely partitioning level mapping. This notion 
is crucial in the context of a termination analysis for tabled logic programs. 
In particular, in the termination condition of [7], it is required that the level 
mapping is finitely partitioning on the call set of the program w.r.t. the set of 
queries for which one wants to prove termination (see also Theorem 1). 

Definition 13 (finitely partitioning level mapping). - | | , 

. . y -SC Bp . , , . y I . I . , finitely partitioning on S . 

VnelN: S((|.|)-i(n)n5) <oo .... ft.. .. ... „ _ 

It is easy to see that if the set S is finite, all level mappings are finitely 
partitioning on S (in particular this is the case if the Herbrand Universe is 
finite). Intuitively it is clear that, for infinite sets S closed under substitutions, 
a level mapping |.|^ is finitely partitioning on S if it takes into account , y. 
argument positions of predicates and functors in S (more precisely, for every 
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atom A in S' and every variable X in A, at least one occurrence of X in A is 
taken into account, i.e. s is not 0 there). We refer to [15] for a formal statement. 

In order to automatize termination proofs, and in particular, in order to have 
a sufficient condition for termination which is stated fully at the clause level (and 
not on “calls”), most approaches rely on the notion of - y- . level mapping. In 
particular, in [8], it is required that the level mapping is rigid on the call set of 
the program w.r.t. the set of queries for which one wants to prove termination. 
A level mapping is rigid on a set of atoms, if the value of an atom of the set is 
invariant under substitutions. As was shown in [3] (see also [15]), a level mapping 
|.|j, is rigid on a set S if it does . take into account . , . argument positions 

of predicates and functors in S (more precisely, for every atom A in 5" and every 
variable X in A, no occurrence of X in A is taken into account, i.e. s is 0 there). 

As follows from the informal argumentation above, the rigidity condition on 
the level mapping, as it appears in the automated termination analysis of [8], is 
difficult to combine with the condition on the level mapping to be finitely parti- 
tioning, as it appears in the termination condition for tabled logic programs of 
[7]. In our search for automatizable termination proofs for tabled logic programs, 
we solve this problem by abandoning the rigidity requirement and using other 
syntactical conditions on the program and set of queries which allow us to for- 
mulate an easy to automatize termination condition which is stated fully at the 
clause level. In order to find such conditions we use mode and type information. 
The following concepts will be useful. 

Definition 14 (measuring only/all input). . [.[^ , 

- - . s - SCB§ 

.. . |.|^ measures only input positions in 5- 
- y-. S i e {I, . . . ,n} s{pi) ^ 0 .. rupii) 

- .. . |.|g measures all input positions in S . 
p/n - y - S mp{i) = In .. s{pi) yf 0 

//m m > 0 - y - . , . , , . . 

* G {0, . . . , to} 

In the case of simply moded programs and queries, a level mapping is finitely 
partitioning on the call set if it measures input positions in the call set. 



Proposition 2. . P . 




- 

Call{P,S) . [.[,! ' .. . .. 


Call{P,S) 



The notion of a level mapping measuring . . input positions in Call(P, S) 

will allow us to state the termination conditions fully at the clause level. Note 
that the conditions on a level mapping to measure all and only input positions 
in the call set, can be combined without problems. 



p/n 



= In 
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3 Quasi-Termination 

We recall the definition of quasi-termination [7]. 

Definition 15 (quasi-termination). . P , ^ SC Bp 

P quasi-terminates w.r.t. S. , A ..... A £ S .. , . , 

PU{^A} ^ , 

Note that the program of Example 1 quasi-terminates w.r.t. {nat(X)}. 
In [7, Lemma 3.1] the following equivalence was proven: P, , ... , . . / 

S. , - A. S Call{P,{A}). .. . It is easy to see that LD-termination 

of P w.r.t. S (i.e. termination of P w.r.t. S under LD-resolution) implies quasi- 
termination of P w.r.t. S. Note that when a program is quasi-terminating w.r.t. a 
query Q, there are a finite number of trees in the LG-forest, all of them have finite 
branches, but, possibly, they have infinitely branching nodes. The stronger notion 
of . - . _ . takes this source of nontermination into account. Namely, a 

program P is said to LG-terminate w.r.t. S iff for all A such that A G S, the 
LG-forest for PU{<— A} consists of a finite number of finite LG-trees. Note that 
the program of Example 1 does not LG-terminate w.r.t. {nat{X)}. By the 
lack of space, we will not consider LG-termination in this paper. We refer to [15] 
instead. 

In [7], the quasi-acceptability condition was introduced and it was shown to 
be equivalent with quasi-termination [7, Theorem 3.1]. 

Theorem 1 (quasi-acceptability w.r.t. S). . P . y -SC 

Bf P. . . . . , . S. .. . . . . .. y 1.] . . .. . 

y . Call{P,S) .. .... 

. .. A. ... . AGCall{P,S) 

<— Pi, . . . ,P„- P ... . mgu{A, H) =9 . . 

. i G {1, ... ,n} . - Oi-i 

(Pi,...,P,_i)0 

|y4| > ]P,00,_ll. 

The aim of this paper is to extend the automatic constraint-based termination 
analysis for LD-resolution of [8] , to prove quasi-termination in an automatic way. 
In order to do so, we need (1) a termination condition which is stated fully at 
the clause level (and not on “calls” as in the quasi-acceptability condition of 
Theorem 1), and (2) a syntactical condition on a level mapping in order to be 
finitely partitioning on the call set. In the next Subsection 3.1, we present such 
a condition in the case of SMWT programs and queries. As we will point out 
in Subsection 3.2, this condition forms the basis for extending the automatic 
approach of [8], in order to prove quasi-termination of SMWT programs and 
queries in an automatic way. 
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3.1 Simply Moded Well- Typed Programs and Queries 

Proposition 2 provides us with a syntactical condition on a level mapping to 
be finitely partitioning on the call set of a simply moded program w.r.t. a set 
of simply moded queries: the level mapping has to measure all input positions 
in the call set. In order to be able to state a condition for quasi-termination 
which reasons fully at the clause level, we use Proposition 1. In Proposition 1, 
we proved that for a SMWT program P and query <— A, such that the heads of 
the clauses of P are input safe, the input arguments of A get never instantiated 
during an LD-derivation. This allows us to state a condition at the clause level, 
if we require in addition that the level mapping measures only input positions 
in the call set. 

Theorem 2. . P ^ -SC Bp , . , 

- . - - P - , - . . - - 

- M, P ^ , . 

. Call{P,S) .... 

~ . H ^ Bi, . . . , Bn - P 

— i G {1, ..,n} _ . ... if) _ . . .. . M \= {Bi A ... A Bi-i)ip 

. {B^yy-^, . . . , e caii{p, sy^ 

\Hy\^ > 

.. P. . , . ^ . S P . . . . . y . S 



Note that, because P and S are well-typed, it follows that, if the condi- 
tions of the theorem are satisfied, i.e. if ■!/: is a substitution such that M \= 
(Pi A ... A P^-OV' and {Hipy^, (PiV')^”, ■ • ■ , e Call{P, then HiP 

is correctly typed in its input positions, (Pi, . . . ,Pi_i)'0 is correctly typed and 
Biij) is correctly typed in its input positions. 

We want to note that Theorem 2 can also be applied in the case of . 

^ . . programs and queries. We already noted in Subsection 2.2 that 

the notion of well-modedness [1] is a special case of the notion of well-typedness: 
namely, well-typedness collapses to well-modedness if the types of all predicate 
positions are defined as Ground. Recall also from Subsection 2.2 that all terms 
are generic expressions for the Ground type, so the heads of all clauses of a 
well-moded program (in which we defined the types of all predicate positions as 
Ground) are trivially input safe. Finally, note that in the case of a well-moded 
program and set of queries, the condition on the level mapping to measure only 
input positions in the call set, has as a consequence that the level mapping is 
rigid on the call set. We refer to [15] for more details. 

Let P be the following program computing the cyclic permutations 

of a list. 

splitlast{[X],[], X) <— 

splitlastl[X\L], [Ar|i?],T) <— splitlast(L, R,Y) 
cycperm{L,L) <— 

cycperm{L, R) <— splitlast(L,T,X),cycperm{[X\T],R) 
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with splitlast{< In : List >, < Out : List >, < Out : U >) and cycperm{< In : 
List >, < Out : List >). Let S be the set of queries {cycperm{l, X) \ I G List}. 
We prove that P quasi-terminates w.r.t. S by applying Theorem 2 (note that P 
even LG-terminates w.r.t. S, a proof can be found in [15]; note however that P 
does not LD-terminate w.r.t. S). Let’s abbreviate splitlast to sp and cycperm 
to eye. 

P and S are well-typed. This is trivial to see for the set S. The program P is 
well-typed because the following type judgements are true: 



[X] : List 
[X\L] : List 

[X\L] : List A R : List AY : U 
L : List 

L : List A T : List A X : U 
L : List A T : List A X : U A R 



^ [ ] : List AX-.U 
L : List 

=A [Xji?] : List AY : U 
L : List 
=A [X\T] : List 
: List R : List 



Also, P and S are simply moded and the heads of the clauses in P are input 
safe. Let j.j^ be the following level mapping (measuring all and only the input 
positions in Call{P, S)): 

\sp{h,t2,t3)\^ = II h 11^, 

\cyc(ti,t2)\s = II G IL, 

with II . Ils the term-size norm. 

Consider the recursive clause for splitlast. For every ij;, |sp([A'|L], [X\R],Y)'il!\^ = 
II [X\L]il) 11^ = 1 -b II Lip llj, > II Lip llj, = \sp{L,R,Y)ip\^. Consider the recursive 
clause for cycperm. Again, for every ip, \cyc{L, R)ip\,, = || Lip ||^ > || Lip H^, = 
\sp{L, T, X)ip\^. Let Ip he a, substitution such that sp{L, T, X)ip is a consequence 
of the program and such that cyc{L, R)ip, sp{L,T, X)ip and cyc{[X\T], R)ip 
are input-correct w.r.t. Call{P,S). Note that then, || Lip ||^ > 1 -I- || Xip ||^ 
+ IITV^II, = II [X\T]iP\\^. Thus, \cyc{L,R)iP\^ = \\ LiP \\^ > || [X\T]iP \\^ = 
\cyc{[X\T], R)ip\^. Hence, by Theorem 2, P quasi-terminates w.r.t. S. 



3.2 Constraint-Based Approach for Automatically Proving 
Quasi- Termination 

In this subsection, we point out how the constraint-based approach of [8] for 
automatically proving LD-termination of definite programs w.r.t. sets of queries 
needs to be changed in order to prove quasi-termination in an automatic way. 
We restrict ourselves to SMWT programs and queries such that the heads of the 
program clauses are input safe. The basis of the automatic approach towards 
quasi-termination is Theorem 2 of the previous subsection. 

We first recall the main ideas of [8]. In [8], a new strategy for automatically 
proving LD-termination of logic programs w.r.t. sets of queries is developed. 
A symbolic termination condition is introduced, called rigid acceptability, by 
parametrising the concepts of norm, level mapping and model. In order to sym- 
bolize the notion of model, symbolic versions of interargument relations are intro- 
duced. Interargument relations are abstractions of interpretations by specifying 
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relations which hold between the norms of certain arguments of their member 
atoms. In [8], interargument relations express an inequality relation. The rigid 
acceptability condition is translated into a system of constraints on the values of 
the introduced symbols only. A system of constraints identifies sets of suitable 
norms, level mappings and interarguments relations which can be used in the 
termination condition. In other words, if a solution for the constraint system 
exists, termination can be proved. The solving of constraint sets enables the 
different components of a termination proof to communicate with one another 
and to direct the proof towards success (if there is). The method of [8] is both 
efficient and precise. 

We adapt the approach of [8] to prove quasi-termination of SMWT programs 
w.r.t. sets of SMWT queries, such that the clauses of the programs have input 
safe heads, by using Theorem 2. Note that this theorem is stated fully at the 
clause level. As can be seen from Theorem 2, quasi-termination is implied by 
the following conditions on the introduced symbols for norm, level mapping and 
interargument relations. 

(j) The level mapping has to measure all and only input positions in Call(P, S). 
{ii) Every introduced interargument relation must be valid (meaning that the 
induced interpretation is a model of P). 

(in) For every clause P[ ^ in P, for i € {l,..,n}, and for every 

substitution ip such that Blip, . . . , Bi-iip belong to their valid interargument 
relations and such that {HipY'^ ,{BiipY'^ , . . . ,{BiipY'^ S Call{P, S)^"' , the 
weak inequality \Hip\ > \Biip\ must hold. 

Except maybe for condition (i), the modifications needed to transform the 
constraints of [8] into the constraints for quasi-termination, are straightforward, 
and we will not elaborate on them (we refer to [15] and [8]). We show in the 
following example how the first condition (*) is translated into symbolic con- 
straints. 

Recall the SMWT program P and set S of Example 2. Note that 
Call{P,S) = {cyc{l,X),sp{l,R,Y) \ I G List}. We introduce symbolic versions 
for the norm and level mapping (see Definition 12). Let t € U^, then the symbolic 
norm on t is defined as: 

f II X II'® = II [ ] II® = 0 for X G Varp, [ ] G Constp 

ilUf =[-l-]o + [.|.]i||iif + [.|.]2||t2f fort=[tiN, 

with {[.|.]o, [.|.]i, [.|.] 2 } = FC{P). Let sp{ti,t 2 ,tY),cyc{ti,t 2 ) G Bf, then the 
symbolic level mapping is defined as: 

\sp{ti,t 2 ,h)f = spill ti II® -b SP2II t 2 II® -b spall u II®, 

\cyc{ti,t 2 )f =cyci\\ h ||®-bc 2 /C 2 || ^2 ||'® 

with {spi,sp 2 ,sp 3 ,cpci,cpc 2 } = PC{P). 

The condition on the level mapping to measure only input positions in Call{P, S) 
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is expressed in the following constraints: s{cyc 2 ) = 0, s{sp 2 ) = 0 and s{sp 3 ) = 0. 
Condition (i) also requires that the level mapping measures all input positions. 
This gives rise to the following constraints: s{cyci) yf 0, s(spi) yf 0, s([.|.]o) yf 0, 
s([.|.]i) yf 0 and s([.|.] 2 ) ^ 0. 

Note that the level mapping proposed in Example 2 is a solution for the set of 
8 constraints above and indeed, that level mapping measures all and only input 
positions in Call{P,S). 



4 Conclusions and Related Works 

In this paper, we investigated the problem of automatically proving termination 
of logic programs under a tabled execution mechanism. Two works form the 
basis of this paper: [7], where the notion of quasi-termination is introduced and 
a necessary and sufficient condition (quasi-acceptability) is given, and [8] , where 
an automatic approach towards LD-termination is developed. It turned out that 
the rigidity condition on the level mapping, as it appears in the automated 
termination analysis of [8], is difficult to combine with the condition on the 
level mapping to be finitely partitioning, as it appears in the quasi-acceptability 
condition of [7]. In this paper, we showed that for simply moded well-typed 
programs such that the heads of the clauses are input safe, a sufficient condition 
for quasi-termination can be given, which is formulated fully at the clause level 
and which is easy to automatize. We pointed out how this sufficient condition 
can be automatized by extending the approach of [8]. Due to space limitations, 
we did not include our results on the stronger notion of LG-termination. We 
refer to [15] instead. 

Since all programs that terminate under LD-resolution, are quasi-terminating 
and LG-terminating as well, verification of termination under LD-resolution 
using an existing automated termination analysis (such as those surveyed in 
e.g. [6]) is a sufficient proof of the programs quasi-termination and LG-termi- 
nation. In the recent paper [9], Etalle . study how mode information can be 
used for characterizing properties of LD-termination. They define and study the 
class of well-terminating programs, i.e. programs for which all well-moded queries 
have finite LD-derivations. They introduce the notion of well-acceptability and 
show that for well-moded programs, well-acceptability implies well-termination. 

Termination proofs for (S)LD-resolution are sufficient to prove termination 
under a tabled execution mechanism, but, since there are quasi-terminating and 
LG-terminating programs, which are not LD-terminating, more effective proof 
techniques can be found. There are only relatively few works studying termina- 
tion under a tabled execution mechanism. We already discussed the work of [7], 
which forms the basis of this paper. In [13], in the context of well-moded pro- 
grams, a sufficient condition is given for the bounded term-size property, which 
implies LG-termination. [10] provides another sufficient condition for quasi- 
termination in the context of functional programming. In parallel with the work 
reported on in this paper, in [16] the authors of this paper together with K. Sag- 
onas, investigated an orthogonal extension of the work of [7]. Namely, in [16], 
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termination under a mix of tabled and Prolog execution is considered and, be- 
sides a characterisation of the two notions of universal termination under such 
a mixed execution, modular termination conditions are given. An integration 
of [16] with the results of this paper is straightforward. 

We plan to implement the constraint-based technique for automatically pro- 
ving quasi-termination and LG-termination (note that a prototype implemen- 
tation for automatically proving LD-termination [8] exists and is available at 
our site). Also, it remains to be studied how our results can be extended to 
automatically prove quasi-termination and LG-termination for a larger class of 
programs and queries (i.e. for programs and queries which are not simply moded 
well-typed). Finally, the study of termination of normal logic programs under 
tabled execution mechanism is an interesting topic for future research. 
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Abstract. Deterministic conditional rewrite systems permit extra vari- 
ables on the right-hand sides of the rules. If such a system is quasi- 
reductive or quasi-simplifying, then it is terminating and has a com- 
putable rewrite relation. This paper provides new criteria for showing 
quasi-reductivity and quasi-simplifyingness. In this context, another cri- 
terion from [ALS94] will be rectified and a claim in [Mar96] will be 
refuted. Moreover, we will investigate under which conditions the prop- 
erties exhibit a modular behavior. 



1 Introduction 

Conditional term rewriting systems (CTRSs) are the basis for the integration of 
the functional and logic programming paradigms; see [Han94] for an overview 
of this field. In these systems variables on the right-hand side of a rewrite rule 
which do not occur on the left-hand side are problematic because it is in general 
not clear how to instantiate them. On the other hand, a restricted use of these 
extra variables enables a more natural and efficient way of writing programs. 
A paradigmatic example is the Fibonacci system Tifu 

/z6(0)^ (0,s(0)) 

fib{s{x)) ^ {z,y+ z) ^ fib{x) {y, z) 

which has extra variables on the right-hand side of the last rule. The rewrite 
relation induced by the above CTRS is effectively terminating (that is, com- 
putable and terminating) because the system is a ... 

CTRS. This class of CTRSs was introduced by Ganzinger [Gan91] in order to ef- 
ficiently translate order-sorted specifications into conditional many-sorted equa- 
tions. Quasi-reductivity is in general undecidable but sufficient criteria to check 
quasi-reductivity are known [Gan91,ALS94]. The criterion in [ALS94] contains 
a ffaw which will be rectified and the rectified criterion shows in fact 
(a stronger property than quasi-reductivity). 

Similar to the approach of Marchiori [Mar96] , we will show how every deter- 
ministic CTRS TZ can be transformed into an unconditional TRS U {TV) such that 
(simple) termination of U{TZ) implies quasi-reductivity (quasi-simplifyingness) 
of TZ. (A counterexample will show that quasi-reductivity of TZ does not imply 
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termination of U{TZ), even if TZ is left-linear and confluent.) By means of this 
transformational approach, standard methods for proving (simple) termination 
of TRSs can now be employed to infer quasi-reductivity (quasi-simplifyingness). 
Due to the fact that powerful techniques for showing termination like simplifica- 
tion orderings [Der87] and dependency pairs [AG99] are amenable to automation, 
our new criteria now allow us to infer quasi-reductivity (quasi-simplifyingness) 
automatically. This is a major improvement on the known criteria. 

Since both simple termination of U (TZ) and the rectified criterion of [ALS94] 
prove quasi-simplifyingness of TZ, we will investigate the relationship between the 
two criteria. It will be shown that none of the criteria is subsumed by the other. 
En passant, a claim in [Mar96] will be refuted: Simplifyingness of a join CTRS 
TZ without extra variables does imply simple termination of its transformed 
unconditional TRS. 

Finally, we will address the problem of modularity. We will show that quasi- 
simplifyingness is not modular, whereas quasi-reductivity is modular for non- 
overlapping syntactically deterministic CTRSs. Under certain (natural) condi- 
tions, it is modular even for hierarchical combinations of these systems. 

The material presented in this paper complements results reported in [Ohl99] . 

2 Preliminaries 

The reader is assumed to be familiar with the basic concepts of term rewriting 
which can for instance be found in the textbook of Baader and Nipkow [BN98]. 
Here we will only recall the definitions which are crucial to this paper. 

A i? is a binary relation on terms which is 

(i.e., \i s R t, then C[s] R C[t] for all contexts C[ ]) and 
(i.e., \i s Rt, then sa R ta for all substitutions ct). A 
is a rewrite relation which is also a partial order. A well-founded rewrite order 
is called .A is a reduction order which 

contains the proper subterm relation [>, i.e., C[t] >- t for all contexts C[ ] yf □ 
and terms t. 

In a CTRS {T, TZ) rules have the form I ^ r s\ = t\, Sk = tk with 
l,r, s\, . . . , Sk, ti, . . . ,tk G V). I may not be a variable. We frequently ab- 
breviate the conditional part of the rule by c. If a rule has no conditions, we 
write I r, demand that Var(r) C Var{l), and call I — > r an unconditional rule. 
The = symbol in the conditions can be interpreted in different ways which lead 
to different rewrite relations associated with TZ. For instance, in a CTRS 
the = symbol stands for joinability (in)- This paper deals with finite 
CTRSs in which the equality signs are interpreted as reachability (^^). A 

CTRS (IF, TZ) is an oriented CTRS in which the rewrite rules are subject to 
the additional constraint that every tj is a ground normal form with respect to 
TZu, where TZu = TZ}. 

For every rule p : I r ^ c, the set of variables occurring in p is denoted 
by Var{p) and the set of extra variables in p is £Var{p) = Var{p) \ Var{l). A 1- 
CTRS has no extra variables, a 2-CTRS has no extra variables on the right-hand 
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sides of the rules, and a 3-CTRS may contain extra variables on the right-hand 
sides of the rules provided that these also occur in the corresponding conditional 
part (i.e., Var{r) C Var{l) U Var(c)). 

3 Quasi-Reductive Deterministic 3-CTRSs 

First of all, we will review the definition of deterministic systems from [Gan91]. 

deterministic . 

1 < i < k , Var{si) C 

SVar{ti) = Var{ti) \ (Var{l) U U}=i 

The rewrite relation associated with an oriented deterministic 3-CTRS 
TZ is defined by: s ->-tz t if and only if there exists a rewrite rule p : I ^ 
r <1= Si ^ ti, . . . , Sfc ^ tfc in 7^, a substitution a : Var{p) T(lF, V), and a 
context C[ ] such that s = C[l(j],t = C[r(j], and sia tia for all 1 < t < A:. 
We stress the fact that a instantiates every variable in p and not only those 
variables occurring in /; for an extra variable x, xa is determined as follows. The 
conditions are evaluated from left-to-right. Since si contains only variables from 
Var(l), the variables in Var(si) have a binding. Then sicr is rewritten until t\a 
matches a reduct. The term tia may contain extra variables but all of these are 
bound during the match. Now S 2 contains only variables which already occurred 
to its left (in I and ti) and are thus bound. The instantiated term S 2 is then 
reduced until the (partially) instantiated term t 2 matches a reduct and so on. If 
all the conditions are satisfied, then all variables in the conditions are bound in 
the process of evaluating the conditions. Hence the reduct of la is well-defined 
(but in general not unique) because r contains only variables which also appear 
in the conditions or in L 

The next definition is based on the well-known fact that if is a well-founded 
partial order which is closed under contexts, then the order )^st= {>- U >)+ is 
also well-founded ([> denotes the proper subterm relation). 

Definition 2. 

T' 

T{T',V) , , 

ct: V ^T{T',V) 

SjO > tjO 1 < J < * l<y >~st Si+lO" 

sja ^ tja ^ j k , la >- ra 

Quasi-reductive deterministic 3-CTRSs were introduced by Ganzinger [Gan91, 
Def. 4.2] without mentioning that the original signature can be extended. This, 
however, is crucial because otherwise Propositions 4.3 and 4.4 in [Gan91] would 
be incorrect. Finite quasi-reductive deterministic 3-CTRSs have a terminating 
and computable rewrite relation [Gan91,ALS94]. 



(IF, TZ) quasi-reductive 

T T C P >- 

I ^ T Si ^ ti , . . . , si^ ^ t/j, G TZ 
Q <i <k 



Definition 1. 



TZ 



Si 



ti, . ■ 



, Sk 



tk TZ 



Var{l) U U!-=i Var(tj) 
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To start with, there is the following sufficient condition for quasi-reductivity. 

Definition 3. TZ 

TZq TZ C TZq TZq = UpeK 

q p : I ^ -f ^ Si ^ ti,. . . ,Sk ^ tk . 

q{p) = {l^ Si 

I ^ S2 ^ Si ^ ti 

I > Sk 5i > tl, • ■ • , Sfc_i > tk—1 

I > T Si ^ tl, • ■ • , Sk—1 ^ tk—l^ Sk ^ t/j,} 

Proposition 4. TZ 

TZq 

Since TZq is terminating, the relation is a reduction order and it is 
easy to see that TZ is quasi-reductive w.r.t. this order. 

The following example taken from [Mar95] shows that the converse of Propo- 
sition 4 does not hold. 

The normal 1-CTRS TZ 

a ^ c a ^ d 

b ^ c b ^ d 

c ^ e c ^ I 

k ^ I k ^ m 

d ^ m 

A^h{f{a),m) 

h{x,x) g{x,x,f{k)) 
g{d,x,x) A 

f{x) ^ X <J= X — > e 

can be shown quasi-reductive. The system TZq = 7^ U {/(x) ^ x}, however, is 
not terminating because there is the following cyclic derivation 

h{f{a),f{b)) Hfid)J{d)) ^(/(d), /(d), /(*)) 
g{d,f{d),f{k)) g{d, f{m), f{m)) A. 

Ganzinger [Gan91, Prop. 4.3] provided the following sufficient condition for 
quasi-reductivity: Let T' be an enrichment of the original signature T such that 
the order can be extended to a reduction order over T(lF', V). A deterministic 
rule I ^ r ^ Si ^ ti, Sk ^ tk is quasi-reductive if there exists a sequence 
hi{x) of terms in T (IF', V), where x G V, such that I >~ hi{si), hi{ti) > hi+i{si+i) 
for every 1 < i < fc, and hk{tk) ^ r. 

This criterion, however, does not tell us how the terms hi{x) should be cho- 
sen. A systematic way of showing quasi-reductivity consists of transforming a 
deterministic 3-GTRS TZ into an unconditional TRS U (TZ) and showing termina- 
tion of U{TZ). For normal 1-GTRSs, a similar transformation was already given 
in [BK86, Def. 2.5.1]. Marchiori [Mar96,Mar95] studied such transformations of 
1-GTRSs (which he called ) in detail. 
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Definition 6 . 



P 



P '■ 



r ^ c G TZ 

p G 7Z 




T 



Ul- 

Var 



SVar 



Var{t) £Var{t) 

P . I ^ T 5i ^ tl, ■ • ■ , 5|p| ^ t|p| 



t 

U(p) IpI + 1 



I [/f (si, Var(l)) 

Ui{ti,Var{l)) U2{s2,Var{l),£Var{ti)) 

U2{t2,Var{l),£Var{ti)) U^{s3,Var{l),£Var{ti),£Var{t2)) 

Ul'pp\p\,Var{l), £Var(ti), . . . , £Var{t\p\_i)) r 

^ U{n) = Upe^Wip)} . 

•^' = -^UUpe 7 ^,K.<|p|^f Var(r')C 

Var(l') V ^r' G U{U) 

For example, the transformation of the system TZfib yields the TRS 

/z&(0)^ (0,s(0)) 
fib{s{x)) Ui{fib{x),x) 

Ui{{y,z),x) {z,y+ z) 

It turns out that termination of U (TZ) is a sufficient but not a necessary condition 
for quasi-reductivity of TZ. 

Proposition 7 . U( 7 Z) TZ 

The proof of the proposition can be found in [Ohl99] and a similar result for 
normal 1-CTRSs appeared in [Mar96]. In our Fibonacci example, termination of 
the transformed system U (TZfib) can be shown by rpo. Thus the system TZfib is 
quasi-reductive by Proposition 7. 

Example 5 can be used to show that the converse of Proposition 7 does not 
hold. To be precise, it can be shown that h{f(a),f{b)) ^^7(7^) ^ and hence 
U(TZ) is not terminating; see [Mar95]. In Example 5, however, the CTRS TZ is 
neither left-linear nor confluent and one might wonder whether this is essential 
(for 1-CTRSs non-left-linearity is crucial; see [Mar96, Thm. 6.12]). The following 
example shows that left-linearity and confluence of a quasi-reductive 3-CTRS TZ 
are not sufficient to ensure termination of U (TZ) . 

Let TZ contain the rule g(x) k(y) h(x) d, h(x) c(y) and 
the following unconditional rules 

h(d) c(a) h(d) c(b) 

a ^ e b ^ e 

f(k(a), k(b),x) f(x, x, x) f(x, y,z) ^ e 
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We have TZq = TZU {g{x) h{x),g{x) h{x) 4= h{x) d}. Let TZ' contain 

the rule g(x) h{x) and the unconditional rules of TZ. The rewrite relations 
and coincide because the rules g{x) k{y) 4= h{x) d, h{x) c{y) 
and g{x) h{x) 4= h{x) — > d are never applicable (there is no term t such that 
h{t) — d). It can be shown that TZ' is terminating. Hence TZ is quasi-reductive 
by Proposition 4. TZ is also confluent because every critical pair is joinable. The 
transformed system U{TZ) consists of 

g{x) Ui{h{x),x) 

Ui{d,x) U 2 {h{x),x) 

U 2 {c{y),x) k{y) 

and the unconditional rules of TZ. U{TZ) is not terminating because of the fol- 
lowing cyclic derivation 

f{k{a),k{b), U 2 {h{d),d)) f{U 2 {h{d),d),U 2 {h{d),d), U 2 {h{d),d)) 

^uiTZ) /(^ 2 (c(a), d), U 2 {c{b),d), U 2 {h{d),d)) 
ma),k{b),U 2 {Hd),d)). 

Observe that the preceding derivation is not innermost and it has been shown 
in [Ohl99] that this is essential. 

Theorem 9. TZ U(TZ) 

Another sufficient criterion for quasi-reductivity is given in [ALS94, Lemma 3.1]. 
In order to formulate it (claim below), we need the following definition. 

Definition 10. p ■. I ^ r ^ s\ ^ Sk ^ tk 

TZ p 

X € EVar{p) a{x) , ,, xG Var{ti) 

ipi = id 

ipi+i = {x ^ Sa(x) I X G Var(fi, . SVar{p)} l<i <k 

Si = P>i{Si) 

p / ^ r 4= Si ^ c, . . . , Sfc ^ c , c . 

r = pk+i{r) 

Claim: Let be a reduction order and let 7^ be a deterministic 3-CTRS. If, for 
every rule p in 7^, the backward substituted rule p satisfies I si for 1 < i < 
k and I >- r, then TZ is quasi-reductive w.r.t. 

The next example, however, refutes the claim. 

Consider the deterministic 3-CTRS 
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Its backward substituted system TZ consists of the two unconditional rules of TZ 
and the conditional rule a b ^ b c. The unconditional TRS TZu obtained 
from TZ by dropping the conditions is terminating. Hence the order 
is a reduction order which satisfies the above claim. The original system TZ, 
however, is not even terminating because there is the infinite rewrite sequence 

f {d)^nf {a)^nf {d)^n — 

The criterion will be rectified in the next section. 

4 Quasi-Simplifying Deterministic 3-CTRSs 

Definition 12. 7^ quasi-simplifying . . 

By definition, quasi-simplifyingness implies quasi-reductivity. We shall see later 
that the converse is not true. In contrast to quasi-reductivity, quasi-simplifying- 
ness is independent of signature extensions in the following sense: if a deter- 
ministic 3-CTRS {!F ,TZ) is quasi-simplifying w.r.t. a simplification order on 
T(lF',V), where T C T' , then {T,TZ) is quasi-simplifying w.r.t. the restriction 
of on T(lF, V). The simple proof of this fact is left to the reader. 

Quasi-simplifyingness is closely related to simplifyingness. A join 1-CTRS TZ 
is . if there is a simplification order such that I >- r, I >- Sj and I >- tj 

for every I ^ r si I ti,. .. ,Sk i tk € TZ; see [Kap87]. For oriented 1-CTRSs, 
the condition I >- tj can be dropped because the term tj is never reduced. Thus 
an oriented 1-CTRS 7^ is if there is a simplification order such 

that I >- r and I >- Sj for every I ^ r ^ s\ ^ t\, Sk ^ tk va TZ. Obviously, 
every simplifying oriented 1-CTRS is quasi-simplifying. 

Next we will provide several criteria which guarantee quasi-simplifyingness. 
To this end, we need the following lemmata. 



Lemma 13. 


TZ 


T 




TZU£mb{tF) . 


£mb{T) 


f{xi,.. 


• 1 ^n) ^ ^j f € 


n>l j G {1,..., 


Xi, . . 


• 1 





A proof of the preceding lemma can be found in [Zan94] and the proof of the 
next lemma is straightforward; cf. [Ohl94, Lemma 8.1.9]. 

Lemma 14. TZ ... . 

TZs = TZuiT {I ^ Sj \ I ^ r ^ si^ ti,. . . ,Sk ^ tk & TZ; I <j <k} 



TZ 



TZu^J {I ^ Sj \ I r Si [ti,. . . ,Sk [tk & TZ; I < j < k} 
\J {l^tj \ I ^ r ^ Si [ti,. . . ,Sk [tk & TZ; l<j<k}. 
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The first sufficient criterion uses the CTRS TZq from Definition 3. It is actually 
a characterization of quasi-simplifyingness. 

Proposition 15. TZ T 

TZq U £mb{T) 



“if”: It is not difficult to prove that ^ simplification order^ 

and that TZ is quasi-simplifying w.r.t. that order. 

“only-if”: Let TZ be quasi-simplifying w.r.t. the simplification order )^. We show 
vjSmb(j^) — Clearly, it is sufficient to show that s -^TZqijemb(j^) t implies 
s >- t. If s ^smb(j^) tj tiiEit is, s = C[f{ui, . . . ,Un)] and t = C[uj] for some 
f € J-, then the assertion follows from the fact that has the subterm property 
and is closed under contexts. We prove by induction on the depth of the rewrite 
step that s ^nqU£mb{y^) t also implies s t. Consider the reduction step s = 
C[la] ^TZqU£mb{y^) C[si+icr] = t, where the rewrite rule I Si+i si ^ ti. 
Si ^ ti is used (let s^+i = r), so SjO u£mb{F) 1 < J < b One has 

sja ^ tja by the inductive hypothesis. It then follows from quasi-simplifyingness 
that la >- Si+ia. We eventually infer s y t because is closed under contexts. 



The second sufficient criterion uses the transformation of Definition 6. 

Proposition 16. U(TZ) . . . TZ 

By Lemma 13, U{TZ) U£mh{!F') is terminating. We show ^nqij£mb(j^) C 
~^u (ji)vj£mb(j^')' proposition then follows from Proposition 15. If s -^smb(j^) 

t, then we have s t because T C T' . We prove by induction on the 

depth of the rewrite step that s ^nqU£mb{y^) t implies s ^u{n)L>£mb{y^') Con- 
sider the reduction step s = C[la] ^TZqU£mb{:F) ^[si+icr] = t, where the rewrite 
rule I Si+i <J= Si ^ fi, . . . , Si ^ ti is used, so sja ^^^u£mb(j^) 

1 < j < b One has sja ('R.)yj£mb(j^') inductive hypothesis. Thus, 



^U(K) 

~^UCR)U£mb(F') 

^u{n) 



Ui(si,Var{l))a 
Ui{ti,Var{l))a 
C /2 (s 2 , Var{l),£Var{ti))a 



'U{n)u£mb{y^') 

■u(u) 



U^{ti,Var{l),£Var(ti), . . . , £Var{U-i))a 
C/f+i(si+i, Var(l),£Var(ti), . . .,£Var{ti))a 

Si+ia. 



We have already seen that U{TZfib) is simply terminating, hence TZfib is quasi- 
simplifying according to Proposition 16. 

In order to rectify [ALS94, Lemma 3.1], it is sufficient to replace “reduction 
order” with “simplification order” . This yields the third sufficient condition for 
quasi-simplifyingness . 

^ This is true because we consider finite signatures only; see [MZ97] for details on 
infinite signatures. 
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Proposition 17. (!F,TZ) 

(Tu{c},n) . . {T,n) 

If (iFU {c},7^) is simplifying, then there is a simplification order such 
that I >- r and I >- Si for 1 < i < fc for every backward substituted rule p of a 
rule p = I ^ r ^ Si ^ ti, . . . , Sk ^ tk from TZ. 

We will only show that the first condition of Definition 12 (if SjC ^ tja for 
every 1 < j < t, then la >- Si+icr) is satisfied. The second condition (if sju > tja 
for every 1 < j < fc, then la >- ra) follows by similar reasoning. It will be shown 
by induction on i that sja ^ tja for every 1 < j < i implies Si+iCT ^ s^+ict. 
This is sufficient because I >~ further implies la >- Si+iCT ^ Si+ia. The 
base case i = 0 holds as si = si. In order to show the inductive step, note 
that Si+iCT = (fii+i{si+i)a. Let y € Var(ti, . . . ,ti) Cl EVar{p). According to the 
inductive hypothesis, Sa(y)a ^ Sa{y)a. Therefore, Sa(y)a >i Sa(y)a >i ia(y)a ^ ya 
and hence ipi+i{y)a = 'Sa(y)a ^ ya. Now Sj+ict ^ Si+icr is a consequence of 
the following observation: If ui ^ ui,...,u„ ^ Vm then C[ui,U 2 , ■ ■ ■ ,Un] h 
C[vi,U 2 , ■ ■ ■ , Un] ^ ^ ^[ui, . . . , Vn] since is closed under contexts. 

Proposition 17 can also be used to show quasi-simplifyingness of TZfib- This can 
be seen as follows. TZfib consists of the rules 

/z&(0)^ (0,s(0)) 

fib{s{x)) ifib{x),fib{x) + fib{x)) <= fib{x) c 

By Lemma 14, simplifyingness of TZ fib is equivalent to simple termination of the 
TRS {TZfib)s and simple termination of this TRS can easily be shown by rpo. 

Since both Proposition 16 and Proposition 17 are sufficient conditions for 
proving quasi-simplifyingness, it is natural to ask whether one is subsumed by 
the other. This is not the case as the following examples will show. 

Let TZ = {/(s(x)) ^ f{s{y)) <= f{x) f{s{y))}. It is fairly simple 
to show that U{TZ) is simply terminating. To verify that Proposition 17 is not 
applicable is equally simple; see [ALS94] . 

Consider the oriented 1-CTRS (IF, TZ) consisting of the rules 

a ^ d a — > e 

b ^ d 6 — > e 

A^h{f{a),m) 

h{x, x) g{x, x) 
g{d, e)^ A 

f{x) ^ X X ^ d 

Its backward substituted system TZ over T = T U {c\ \s obtained from TZ by 
replacing its last rule with f{x) ^ x ^ x ^ c. We claim that TZ is simplifying. 
By Lemmata 13 and 14, it suffices to show that TZg U Emb{TF) is terminating. 
For an indirect proof of the claim, suppose that there is an infinite TZs U£mb{lF) 
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reduction sequence. It is not difficult to see that in this case there must be a cycle 

^ A. If Hmjm -± a, 

then there must be a term t such that 

h{f{a),m) g{d,e) ^n.u£mb(F)^- 

So t must be a common reduct of /(a) and /(&) and t must rewrite to d and e. 
The common reducts of /(a) and f{b) are f{d), /(e), d, and e. Neither of them 
reduces to both d and e. We conclude that TZs U £mb{!F) is terminating. Thus 
TZ is simplifying and, according to Proposition 17, TZ is quasi-simplifying. 

U (77.) is obtained from 77 by replacing the conditional rewrite rule with the 
unconditional rewrite rules f{x) U{x,x) and U{d,x) x. The following 
cyclic derivation shows that U (77) is not simply terminating. 

A^uCR) Hf{a),f{b)) h{U{a,a),U{b,b)) h{U{d,e),U{d,e)) 

^u{n) g{U{d,e),U{d,e)) g{d,e) ^u(n) 

The preceding example is also interesting because it refutes the claim below 
which is a reformulation of [Mar96, Lemma 5.6]. Let us first review the definition 
of the transformation U as given in [Mar96, Def. 4.1]. Given a join 1-CTRS 77 
and a rule p : I ^ r ^ si I ti, . . . , Sk I G TZ, the transformation U(p) yields 
the set which contains the two unconditional rules 

I Up{si,ti, ...,Sk, tk, Var{l)) 

Up{xi,xi, ...,Xk, Xk,Var{l)) r 

where x\,...,Xk are fresh and pairwise distinct variables. Moreover, U(77) is 
defined as usual: U(77) = Up 67 ?,U(p)- 

Claim: If a join 1-CTRS 77 is simplifying, then the transformed TRS U(77) 
is simply terminating. 

If we view the system 77 from Example 19 as a join CTRS, then U(77) = 
77' U {/(x) ^ [/(x, d, x), t/(xi, xi, x) ^ x}, where 77' consists of the uncondi- 
tional rules of 77. As in Example 19, it can be shown that the system 77'U{/(x) ^ 
X, /(x) ^ d} is simply terminating. Thus the join 1-CTRS 77 is simplifying ac- 
cording to Lemma 14. On the other hand, the transformed system U(77) is not 
simply terminating because there is a cyclic derivation as in Example 19. 

5 Modularity 

In this section, we will investigate under which conditions quasi-reductivity and 
quasi-simplifyingness are modular. The reader is assumed to be familiar with the 
concepts of the field of modularity. Details can be found e.g. in [Ohl94,KR95]. 
Let 77 be a CTRS over the signature T . A function symbol / G iF is called a 
if there is a rewrite rule I ^ r ^ c G TZ such that / = root{l). 
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Function symbols from T which are not defined symbols are called 
If TZ\ and 7^2 are CTRSs over the signatures Ti and T 2 , respectively, then their 
is their union 7^ = 7^i U7^2 over the signature T = Its 

set of defined symbols is I? = U I ?2 and its set of constructors \s C = T\T>, 
where T>i {Ci) denotes the defined symbols (constructors) in TZi. 

(1) 7^1 and 7^2 are . if iFi n 1 F 2 = 0. 

(2) TZi and 7^2 are if iFi n 1F2 = Ci n C 2 (C C). 

(3) TZi and 7^2 form a hierarchical combination of base 7^i and extension 7?-2 if 
Cl n 7?2 = 77i n 7?2 = 0- 

A property V is for a certain class of CTRSs if, for all CTRSs (lFi,7^i) 

and {J^ 2 ,T^ 2 ) belonging to that class and having property V, their union U 
1F2,7 ^i U 7 ^ 2 ) also belongs to that class and has the property V. 

It is well known that simple termination is modular for constructor-sharing 
TRSs; see [K092,MZ97]. It readily follows from Lemma 14 that simplifying- 
ness is also modular for finite constructor-sharing 1-CTRSs. Therefore, if quasi- 
simplifyingness of two constructor-sharing 3-CTRSs TZi and 77-2 can be shown by 
Proposition 17, then 7^i U 77-2 is also quasi-simplifying. This is because the sim- 
plifying backward substituted 1-CTRSs 7^i and 7^2 are also constructor-sharing. 
Hence it is a bit surprising that quasi-simplifyingness is in general modu- 
lar for disjoint deterministic 3-CTRSs. The next example which is taken from 
[Mid93] is a counterexample. 

Consider the 1-CTRS 

77.1 = {fix) fix) X ^ a,x ^ b} 

over the signature !Fi = {f,a,b}. It is not difficult to show that the system 
{fix) x,fix) ^ X <= X ^ a, fix) fix) X ^ a, x ^ 6} is terminating 
because the last rule can never be applied. Hence 77i is quasi-simplifying by 
Proposition 15. The TRS 

_ J or(x, y) ^ X 
^ \ or(x, y) 

is obviously quasi-simplifying, too. The combined system 77i U 77-2, however, 
is not even terminating: fioria,b)) ^■r.iU'R .2 fioxia,b)) is a cyclic derivation 
because or(a, b) ® and or(a, b) -^^2 b- 

Quasi-simplifyingness of 77i cannot be proven by Proposition 16 because 

(fix) ^Uiix,x) 

[/(77i) = < Uiia,x) U 2 ix,x) 

[ U 2 ib,x) fix) 

is not simply terminating as the following cyclic derivation shows: 

fiUiia,b)) ^u{Tii) UiiUiia,b),Uiia,b)) Ci(a, [/i(a, 6)) 

^uCRi) U2iUiia,b),Uiia,b)) 172(6, t/i(a, 6)) 

-^u{ni) fiUiia, b)). 
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This is not surprising because the combined system of two constructor-sharing 
deterministic 3-CTRSs TZi and TZ 2 is quasi-simplifying if both U{TZi) and U{TZ 2 ) 
are simply terminating. This fact is an easy consequence of the following simple 
generic proposition. 

Proposition 21. TZ\ 7^.2 

7^1 U T?.2 

C/(7^l) t/(7^2) 

C/(7^l) C/(7^2) , . , . 



Since simple termination is a modular property, the combined system 
U{TZ\) U U ( 7 ^ 2 ) is simply terminating. Now the proposition follows from U{TZ\ U 
T^2) = U{TZi) U [ 7 ( 7 ^ 2 ) in conjunction with Proposition 16. 

A similar result can of course be stated for quasi-reductivity (just replace 
simple termination with termination). However, better results can be obtained 
by taking advantage of the implications U{TZ) is terminating 7^ is quasi- 
reductive (Proposition 7), 7^ is quasi-reductive U (TZ) is innermost terminating 
(Theorem 9), and the fact that termination and innermost termination coincide 
for non-overlapping TRSs; see [Gra95, Thm. 3.23]. 

Proposition 22. TZi 77.2 
77i U 77.2 

C/(77i) C/(772) , . , . 

C/(77i U 772) 

Since 77i and 772 are quasi-reductive, the transformed TRSs U{TZi) and 
1 /( 772 ) are innermost terminating according to Theorem 9. Their combination 
[/(77i) U 1 /( 772 ) = C/(77i U 772 ) is also innermost terminating because innermost 
termination is modular. Therefore, termination of C/(77i U 772) is a consequence 
of its non-over lappingness; see [Gra95, Thm. 3.23]. Now the assertion follows 
from Proposition 7. 

However, non-overlappingness of U{TZ) is not implied by non-over lappingness of 
77. For example, the system TZ = {a ^ b <= b ^ a} is non-overlapping but 
U{TZ) = {a ^ U{b), U{a) h} is not. The situation is different for syntactically 
deterministic 3-GTRSs. 

Definition 23. 77 syntactically deterministic 

I ^ r ^ Si ^ ti, Sk ^ tk 77 ti 1 < i < k . 

2 7? 

Syntactically deterministic GTRSs are a natural generalization of normal GTRSs. 
For example, the Fibonacci system TZjib is syntactically deterministic. The proof 
of the next lemma is straightforward; see [Ohl99]. 

^ A constructor term is a term without defined symbols. 
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Lemma 24. 



U{U) 

n 



Lemma 24 can be refined to demand only exactly what is required by the proof. 
For instance, the 3-CTRS TZ need not be syntactically deterministic; it is suf- 
ficient to demand that no left-hand side of a rule from TZ overlaps a term ti 
of another rule ^2 ^ ^ si ^ ti, • • ■ , Sfc ^ tfc from TZ. On the other hand, 

the example before Def. 23 shows that the lemma does not hold for strongly 
deterministic CTRSs (see [ALS94] for a definition of this notion) . 

Next we will prove a modularity result for hierarchical combinations of CTRSs 
with extra variables on the right-hand sides of the rules. Let us first review some 
formal definitions. Let 7^ be a CTRS and T> be the set of its defined symbols. 
As defined in [KR95,Mar95], the dependency relation on I? is the smallest 
quasi-order satisfying f '^d 9 whenever there is a rule I ^ r ^ s\ ^ , Sk ^ 

tk G TZ such that root{l) = / and g G T> occurs in one of the terms si, . . . , Sk,r. 
If TZi and TZ 2 form a hierarchical combination, then the set of defined symbols 
T >2 of TZ 2 is split into two sets = {f \ f G T> 2 , f hd 9 ior some g G T>i} and 
T >2 ='D\T>\. Krishna Rao [KR95] proved the following theorem. 



Theorem 25. 7^i TZ 2 

7^2 

root{t) ^d root{l) , t 

TZ\ TZ 2 



TZi I — ^ T G TZ2 

t r root{t) G T>\ 
ViUVl 

TZ\ U TZ 2 



The combination of Lemma 24, Proposition 22, and Theorem 25 yields the fol- 
lowing theorem. 



Theorem 26. 7^i TZ 2 



TZ\ U TZ 2 



I ^ T ^ tl, . . . , ^ TZ2 

I T)i 

Sj I < j < k + 1 , Sfc+i = r U I ?2 

t Sj , root{t) G T>1 root{t) ^d root{l) 

ViUVl 

Sj+i,...,Sk,Sk+i f GV\ , f>droot{l) 

The combined system U{TZi) U U{TZ 2 ) = U{TZi UTZ 2 ) is non-overlapping 
because the TRSs U{TZ\) and 17(7^2) are non-overlapping by Lemma 24 and 
every rule I ^ r ^ s\ ^ Sk ^ tk va TZ 2 satisfies: neither I nor one of 

the terms t\,. . .tk contains a symbol from T>i. For the same reason, TZi U 7^2 
is non-overlapping and syntactically deterministic. We claim that U{TZ 2 ) is a 
proper extension of U{TZ\). Since innermost termination is modular for proper 
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extensions by Theorem 25, it then follows from Proposition 22 that TZi U 7^2 is 
quasi-reductive . 

In order to prove the claim, consider p : I r si ^ 
tk € T ^-2 and its transformation U{p). If root{l) G T> 2 , then none of the terms 
si, . . . , Sfc, Sfc+i(= r) contain a symbol from T>i U T >2 and every rule in U{p) 
satisfies the proper extension condition. Thus, suppose root{l) G T >2 and let j, 
1 < J < fc+ 1, be the smallest index such that sj contains a symbol from ViUV^. 
Every rule/ ^ C/f(si,...), C/f(ti,...) ^ U^(s 2 ,...), ■■■, Uf_ 2 (tj- 2 , ■ ■ ■ ) 
C/J_i(sj-i, ■ ■ ■ ) vacuously satisfies the proper extension condition. Observe that 
uft, root{l) can only hold if one of the terms s^+i, . . . , Sfc, contains a 
symbol / with / root{l) (which further implies / G T>1). This, however, is 
impossible because of assumption (3). Now the rewrite rule . . .) 

Uj{sj,...) satisfies the proper extension condition by assumption (2) because 
for every subterm t of Uj{sj,...) with root{t) G V\ and root{t) 
have root{t) ^d root{l). The remaining rules . . . ) ^ Uj^i{sj+i, ■ ■ ■), ■ . ■ , 

U^{tk, ■ ■ ■) r satisfy the proper extension condition because of assumption 
(3) and the resultant fact that U[ root{l) for every j + 1 < / < fc. 

As an example, consider the quasi-reductive systems TZ+ = {0-|-y ^ y, s{x)+y 
s(x + y)j and TZfib- Since TZ+ and TZfib meet the requirements of Theorem 26, 
their hierarchical combination TZ+ U TZ fib is quasi-reductive as well. 

Condition (1) in Theorem 26 guarantees that the system U{TZi) U U{TZ 2 ) is 
non-overlapping. The following example shows that condition (2) is necessary. 
The quasi-reductive non-overlapping syntactically deterministic 3-CTRSs TZ\ = 
{a ^ b} and 7^2 = {f(x, x) ^ c <= f{a, h) c} form a hierarchical combination. 
If 7 ^iU 7^2 were quasi-reductive w.r.t. an order )^, then f{b, b) )^st /(o, b) >~ f{b, b) 
would hold, but this contradicts the irrefiexivity of >~st- Finally, we exemplify 
the necessity of condition (3). TZi and TZ^ = {c ^ d ^ a ^ b, c ^ d} form a 
hierarchical combination. Here si = a contains a symbol from T>i and S 2 = c 
contains c G T >2 with c ^d root{l). If TZ\ U TZ^ were quasi-reductive w.r.t. an 
order then c>~at c would hold, but >~st is irrefiexive. 



6 Related Work 

One of the anonymous referees pointed out that a transformation similar to the 
one from Definition 6 was independently found by Marchiori [Mar97, Def. 4.1]. 
Our transformation differs only slightly from Marchiori’s: in the sequence Var(l), 
EVar{t\), . . . ,SVar{ti) every variable occurs exactly once which is not the case 
in the sequence VAR(/, ti,. . . ,ti) from [Mar97, Def. 4.1]. The results of the paper 
at hand, however, are completely different from the ones reported in the tech- 
nical report [Mar97], except for one: Proposition 7 is akin to [Mar97, Lemma 4.6]. 

Acknowledgements: I thank Michael Hanus for the (email) discussion which 
led to the development of the transformation U. I am also grateful to Aart 
Middeldorp and the anonymous referees for their comments. 
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Abstract. We present a simple generic framework to solve constraints 
on any domain (finite or infinite) which has a lattice structure. The ap- 
proach is based on the use of a single constraint similar to the indexicals 
used by CLP over finite domains and on a particular definition of an 
interval lattice built from the computation domain. We provide the the- 
oretical foundations for this framework, a schematic procedure for the 
operational semantics, and numerous examples illustrating how it can 
be used both over classical and new domains. We also show how lattice 
combinators can be used to generate new domains and hence new con- 
straint solvers for these domains from existing domains. 

Keywords: Lattice, constraint solving, constraint propagation, indexi- 
cals. 



1 Introduction 

Constraint Logic Programming (CLP) systems support many different domains 
such as finite ranges of integers, reals, finite sets of elements or the Booleans. 
The type of the domain determines the nature of the constraints and the solvers 
used to solve them. Existing constraint solvers (with the exception of the CHR 
approach [7]), only support specified domains. In particular, the cardinality of 
the domain determines the constraint solving procedure so that existing CLP 
systems have distinct constraint solving methods for the finite and the infinite do- 
mains. On the other hand, CHR [7] is very expressive, allowing for user-defined 
domains. Unfortunately this flexibility has a cost and CHR solvers have not 
been able to compete with the other solvers that employ the more traditional 
approach. In this paper we explore an alternative approach for a flexible con- 
straint solver that allows for user and system defined domains with interaction 
between them. 

* This work was partly supported by EPSRC grants GR/L19515 and GR/M05645 and 
by CIGYT grant TIG98-0445-G03-03. 
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Normally, for any given domain, a solver has many constraints, each with 
its own bespoke implementation. The exception to this rule is CLP(FD) [4] 
which is designed for the finite domain of integers and based on a single generic 
constraint often referred to as an. ... . The implementation of indexicals uses 

a simple interval narrowing technique which can be smoothly integrated into the 
WAM [2,6]. This approach has been shown to be adaptable and very efficient 
and now integrated into mainstream CLP systems such as SICStus Prolog. 

This paper has two contributions. First, we provide a theoretical framework 
for the indexical approach to constraint solvers. This is formulated for any or- 
dered domain that is a lattice. We have observed that most of the existing con- 
straint solvers are for domains that are lattices. Thus our second contribution is 
to provide a theoretical foundation for more generic constraint solvers where a 
single solver can support any system or user-defined domain (even if its cardinal- 
ity is infinite) provided it is a lattice. One advantage of our framework is that, 
as it is based on lattice theory, it is straightforward to construct new domains 
and new constraint solvers for these domains from existing ones. In this paper, 
we describe different ways of performing these constructions and illustrate them 
by means of examples. 

The paper is structured as follows. Section 2 recalls algebraic concepts used 
in the paper. In Section 3 the computation domain, the execution model and a 
schema of an operational semantics are described. Section 4 shows the genericity 
of the theoretical framework by providing several instances which include both 
the common well-supported domains as well as new domains. Section 5 describes 
with examples how the framework can be used on the combination of domains. 
The paper ends with some considerations about related work and the conclusions. 

2 Preliminaries 

2.1 Ordered Sets 

Definition 1. ... . C , . ^ 

C. ordering _ .. .. 

_ A . . . . - , . ^ 

c < c c< c' !\c^ c' , 

c< c c c' W c = c' . 

/ - - c :<c c' / c<d^. c,d € C . C 

... _ . ^ . c, c'gC c ~ c'., . .. 

c<d d < c . c d .. . - . C ^ _ . 

. ordered . . , 

Definition 2. , . . . 

^ . . . C ... dual of C y.. . 

C . . b <c a <c h , 

. . .. dual statement ^ ... 

. . X <y . y di X 
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Definition 3 . _ . C . _ _ . . s. C . lower 

(upper) bound . , ... -EC C., , Wx € E: s ^ x {x ^ s) , . . 

, / „ ---.E. . 

- .. greatest lower bound least upper bound E _ _ . _ glbc{E) 

lubc(E) .. . / - - - glbc{x,y) . . lubc(x,y) ^ . . 

E . / X ^ y 

Definition 4 . . C _ . . 

c,c' G C . c. . predecessor , d . c' successor , c., c<d 

. c- .. immediate predecessor , d c < d _ , - d' & C . . 

.. . c<d' ~<d.. . . . c = d' . immediate successor , c. . ... 

Definition 5 . . . , _ . . C\ - Ci . - - - direct prod- 
uct C = (Ci, C2)- . - - . - ^ - Cl . 

C2 - - - . - - - . - (xi,X2) <C (2/1, 2/2) ^Ci 2/1 - 3^2 ^C2 2/2 

Definition 6 . . ^ . . Ci _ C2 , - - - - lex- 
icographic product C = (Ci,C2). - - . . 

, - - , Cl . C2 - - - . - 

(a;i,a;2) <c (2/1,212) a;i ^Ci 2 /i O'r xx =1/1 and X2 2/2 

2.2 Lattices 

Definition 7 . . C . . L. lattice., , l( , ) 



' ■ l( , ) - - . -/ - x,y € L , , , l( ) - y , l( ) . - . 

S C L .. L. complete lattice 

Definition 8 . . .. . . L , y , 1, ().,.. . 

. the bottom element , L . . lubL(L) .. 

. the top element ., L . . , .... 

- y - / - -- lifted lattice 

L . . LU {J-L, Tl} / . -y y . l( ) - J-L- / - 

. L ... . da G L, ^a ... ,. .l()- - - T^.. 

^ . .. L, .... Vn € L, n ^ T 1, 

Proposition 1 . - . -- . Ci L2 

... . (Li,L 2 ) - -- - y .. - (^1,^2) 



glb{{xi,X2), (211,2/2)) = {glbLdxi,yi),glbL2(x2,y2)) 
glb{{xi,X2), (211,2/2)) = ifxi= yi then (xi, (x 2 , 2/2)) 

elsif Xi -< yi then (xi,X2) 
elsif xx >- yx then (1/1,212) 
else (g/foLi(a;i,2/i),TL2) 

lub- . .... ... glb^ 

Proofs and more information about lattices can be found in [ 5 ]. 
Note that T L2 must be also changed to its dual J-Lj- 
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3 The Constraint Domains 

3.1 The Computation Domain 

The underlying domain for the constraints, denoted here by Dq, is a lattice called 
the , , . _ _ , . . It is assumed that Dq has been lifted to include top 

and bottom elements, T and ^-Da respectively. 

The domain that is actually used for the constraint solving is a set of intervals 
on the computation domain and called the - . , . , - . We allow for the 

bounds of the interval to be either open or closed and denote these bounds with 
open and closed brackets, respectively. Thus, we first need to define an ordering 
between the open and closed right brackets ‘)’, ‘]’ so that the domain of right 
brackets is itself a lattice. 



Definition 9. 




. . . 


bracket domain B. . . 


- _ 


y. 


. - 


— 


- . / 


Ab . . D. . 


. . - 


- ^ } 



Definition 10. . . _ _ . . simple bounded 

computation domain D. .. . . y . (Dq,B) 

By Proposition 1, D is a lattice. For clarity we write a} to express (a,‘}’) in 
D. For example, if Dq is the integer domain, then in D = (Dq,B), 3) :<d 3], 
4] d:D 7], glbi>{3],5]) = 3] and Zu6£)(3], 3)) = 3]. Note that _Ld = J-Dq) and that 
Td = T dJ. 



Definition 11. . , D . mirror of D . .. . y .. 

(Do I B) . D . . , . t € D . - - - 

t — D. _ / / . . {a . a} 



Note that if ti = ai}i,t 2 = 02)2 € D where oi yf 02 we have: 

(1) h ti <t4> ti do h', 

(2) glbjy(ti,t 2 ) = lubi){ti,t 2 ) and lubjj(ti,t^ = ^ 2 ); 

(3) -L-d = Tdo) = (Tdoi T-p = J-Dq] = [J-Dq. 

For example, if Dq = 3?, 3.1] = [3.1 and 6.7) = (6.7, [5.2 do (3-1 d^ [3-1 d^ 
[2.2, gZ%([5.0, [7.2) = [7.2 and Zu%([5.0, [7.2) = [5.0. 



3.2 Constraint Operators 

Let D = (Do, B) be the simple bounded computation domain for Dq. 

Definition 12. . . . . constraint operator (for D). . ,, . 

_ o :: Di X D 2 — > D where Di, D 2 G {D, D}. ... ...... .. o .. 

mirror operator o :: Di x D 2 ^ D. . . . , . G Di . ^2 G 7?2 .. . 

t\Ot2 = t\ o t2 
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Definition 13. . , . , D\, D 2 € {D, D} _ o :: 

DixD 2 ^D. .... . . o. monotonic-, , G Di 

- < 2,^2 G ^2 - -- ■ ti t[ - t2 <D2 t' 2 ^ - 



(tl O t 2 ) <D (t'l O t 2 ) 
(tl O t 2 ) <D (tl O t' 2 ). 



Lemma 1. . ......... . o . 

o. . 



We impose the following restriction on the constraint operators. 

Law of monotonicity for constraint operators. 

• Each constraint operator must be monotonic. 

Normally, a constraint operator o :: Di x D2 D where Di,D2 G 
will be defined by the user or system on Dg and B separately. The value of o on 
D is then inferred from its value on Dg and B so that, ifti = ai}i,t 2 = 02)2 are 
terms in Di,D 2 , respectively, then t\ot 2 = (oi o 02 )(}io} 2 ). Then, if the law 
of monotonicity is to hold in D, it has to hold for the definitions of o on each of 
Dg and B. 

For example, if Dg = 3?, 3.0) + 4.0] = 7.0) where )+] =) and 3.0 + 4.0 = 7.0. 



3.3 Indexicals 

We now add indexicals to the domains D and D. To distinguish between the 
simple bounded computation domain already defined and the same domain but 
augmented with indexicals, we denote the simple bounded computation domain 
for Dg as D®. We assume that there is both a set 0 _d of constraint operators 
defined on D®and a set Vdq of variables associated with the domain Dg. 

Definition 14. . _ . . , I?®. . 

. . _ - , - , Dg .. .. bounded computation domain D for Dg 

.. . D . . 

D = D" U {max{x) \ x G Vdo} U {H o ig | o Dj x Dl ^ D“ G Od, ti G Di,t 2 G Dg}, 
D = D® U {min{x) \ x G Vd„} U {ti o tg \ o :: D} x Dg ^ D” G Od, ti G Di,tg G Dg}. 

.. tGD\D^ 

max{x) = mtn{x), 
t\ O t2 = t\Ot2‘ 

( ), - ( ) . indexicals . , D \ D^ . 

D \ D® . indexical terms 

. - - , - - . D. .. , 

. D® . , t\,t2 G D .. t\ ti,t2 G D® 

tl t2 ti= t'l O t'i, t2 = t '2 O t '2 - t'l t' 2 , t'( t '2 
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3.4 Interval Domain 

Definition 15. . , _ , . _ interval domain , Dq 

, _ y , , - , . (D,D) . simple interval domain 

.. (D^,D^) _ _ 

ri = {si,ti) - r2 = (S2,^2) / - Si,S 2 ,ti,t 2 & D _ 

ri,T 2 G Rd 

ri <Rd r2 ^-D (^1 t2), 

gl-bR^{ri,r2) = {glb^isT,'^), glboiti , t2)), 
lubRR{n,r2) = {lub-^{sT,si),lubD{ti,t2)), 



Rd [-^-Oq, Tdq], 

-Lflc = (Tdo,-Ldo)- 
. {s,t). Rd- inconsistent-, 

S-^ot .. y ....... S 7^_D t 

s = a) - t = a} 

(s, t)- Rd- consistent , ... - - 

range. . , i?|) range expression. . , Rd\Rd 



For simplicity, (s, t) will be written as s, t for both ranges and range expres- 
sions. Thus an element (a},&}) is written as {a, &}. As examples of the defini- 
tions shown above and considering the real domain we have that [2.3, 8.9) 
is a range, [1.4, maa;(x) -1-4.9] is a range expression, [3.0, 4.0) (1.8, 4.5], 

gl6i^„([3.2,6.7],(1.8,4.5])= [3.2,4.5] and ?u6^j^([3.2, 6.7], (1.8,4.5]) = (1.8, 6.7]. 
It is important to note that :^Rr, simulates the interval inclusion. 

3.5 Interval Constraints 

Let Rd denote the interval domain over Dq and let Vdq be a set of variables 
associated with the domain Dq. An interval constraint for Dq assigns an element 
in Rd to a variable in Vd„. 

Definition 16. . ... r G Rd X G Vdo 

a: C r 

. interval constraint , Dq x. ... constrained variable , r. 

y , y , - .. X Q r. . simple , non-simple 

. . ... .... ---xQTRjy. . type constraint 

. . . . , - x::' D q , . . , . . . X C r. consistent 

inconsistent -. r. ... , . ... 

To illustrate these definitions: y,x Integer, b Bool, w,t::' Real, and 
nr.' Natural are examples of type constraints; y C [1,4), b C [True, True], 
and n C [zero, suc{suc{zero))] are examples of simple interval constraints; x C 
min{y),max{y) 3] and t C (1.21*min(r(;), 4.56) are examples of non-simple 
interval constraints where -I- and * are constraint operators for the Integer and 
Real domains. 
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Definition 17. _ . y . . 

r<x 

- '^D • ■■ ■ ■ - - ... 

X ... Cl = X Q ri,C2 = X Q T2 & Cf, 

<Rd T2 Rd- ■- Cf).. 

X E glbR^{ri,r2) 



. - . . X e Vdo 

Du /. .. .... 

Cl C2 - - -y 

glbcf,{ci,C2) = 



Definition 18. . ... constraint store, Dq. .. . , 

. - - - . Do ... , . . . 5. 

. . . . . Xs . ... S. . stable form . stable wrt a set 

of variables X C Xs . . x € X .. . , . . . 

X E c. S .... . , . , . . ^ . S. . 

stable form.. ..... ^ . Xs . . inconsistent.. . . . . 



Definition 19. 
, Dq / 



evals D ^ D" , evals :: D ^ D” 



S 



evals{t) = t 
evals(max{x)) = t 
evals{max{x)) = T £> 
evals{min{x)) = s 
evals {min{x)) = -^d 
evals{ti o t 2 ) = evals(ti) o evals{t 2 ), 



iftGD‘U D“, 
if X ns,t G C‘ , 
if C‘ has no constraint for x, 
*/ X E F, t € C" , 
if C“ has no constraint for x, 



C". S 



An indexical term is a generalisation of the indexical terms provided by CLP 
finite domain languages [4] and allow for infinite as well as finite ranges. 

(Monotonicity of interval constraints) Note that with our definition 
of interval constraint we disallow a constraint such as^ x E [10, 20] — max(y) 
by declaring the operator ’ as —•.•.D x D — *■ D since 2Q]—max{y) ^ D. This 
constraint is non-monotonic since, as the range of y decreases (so that ( ) 
decreases), the term 20]— max(y) increases in D (so that the range of x increases). 
Observe that a range such as [10, 20]— max{y) could not contribute to constraint 
propagation. 



3.6 Execution Model 

The execution model is based on a particular intersection of simple interval 
constraints and on two processes: the stabilisation of a constraint store and the 
constraint propagation. 

It is easier to understand this constraint when written as x E [10, —max{y) + 20]. 
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Intersection of simple interval constraints 

Definition 20. (Id ■ - - - - .. - D ,.^ . . . 

. - . Cl = X Q ri _ C2 = X Q T2 constrained variable x . 

. / 

Cl riD C2 = glbco(ci,C2) 



(a; C n) Dd {x ^ T2) = X n glbR^{n,r2) 

The following properties of Hd are direct consequences of the definition. 

Proposition 2. Hd - x G Vdo - 01,02,03 . . . 

... - . .. . . X ^ . C3 = Cl Cd C2 . Cd . .. 

^ . ■ 4 - ■ 4 . - . 

C3 Cl - C3 ~^Co ^2 

- / -- - .. .. . . - . - , . - 

. ^ —C D ^ —Co C2 .. ^ ^Co ^3 

. (ci (^D C2) = (C2 Hd Cl) 

... . . - . C3 . . , , , , . - (ci Hd 

C3) = C3 - (C3 nu C2) = C3 

If C® is a set of simple constraints with the same constrained variable, then 
we define p|^ = ^ , ^). As a result of the contractance property (1) in 

Proposition 2 we have ^ c®, for each c® S C®. 

Definition 21. . , . .S' . . , . x G 

Xs , X. S . . .. 

stabilised store S' , S- . . , / 

S' = (S\ (J C|)U{ni,(C®)|a;eAs} 

C-® = 0.. nco{C^.) = xQTn, .. 

S' . S , , 

. xG Xs 

, S^S' S'. , S 



Definition 22. y - . ... . c"® 

... X Qs,t . S 

(using S) . .. ... . ■ X Q'si,ti . 

— - s{-)=-i / -- c''®-^^c'. 

, . . .. .. S .. d 



c"® is propagated 

C' 5 (-) = 



- . c 



,ns 



Definition 23. . > - .5 . . C . 

.... ^ ..... 5-. C ^ ^ 

S'^C., C={c\ 3 c”® € S A c”® c} 
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3.7 Operational Schema 

In this section we present as a schema an outline procedure for the execution 
model. Let C be a set of interval constraints to be solved and let V be the set of 
all the variables constrained or indexed in C. Suppose C = C"* U C'"'* where C"* 
is the set of simple constraints in C and C"® is the set of non-simple constraints 
in C. 

Definition 24. _ solution for C. .... R 

/ - - F . - , /. 

(1) Vc" G C® 3c£R.c<Cd c, 

(2) Vc"'* G 3c G R.c :<Cd where c"“ c“ and C C' . 

We provide here a schema for computing a solution for C. Suppose C S 
and S' = 0. The , _ . , is as follows: 

(1) while S 7 ^ s' do 

(2) S C“ %% Constraint Propagation 

(3) 5' := S; 

(4) S'' U C"* S; %% Store stabilisation 

(5) if S is inconsistent then exit with fail endif 

(6) endwhile 

We do not discuss possible efficiency improvements here since the main aim 
here is to provide the basic methodology, showing how the execution method of 
CLP(FD) may be generalised for constraint solving on any domain with a lattice 
structure. If a solution exists, the solution is the set of all the simple interval 
constraints belonging to S. 

Precision. New constraints, created by the propagation step (line 2), are 
added to the set of constraints before the stabilisation step (line 4). Thus, with 
infinite domains, the algorithm may not terminate (note that the constraints can 
be indefinitely contracted in the stabilisation step). To avoid it, we introduce the 
overloaded function precision / 1 which is declared as precision:: 5ft. This 

function must satisfy the following properties: 

(i) precision{r) = 0.0 if r = s, s. 

(ii) precision{r 2 ) < precision{ri) if r2 ( . - - . ) 

To allow for the lifted bounds for infinite domains, let Hr he the highest 
representable real in the computation machine. Then, . . must also satisfy 

— (T-jj, T77) = Hr. The actual definition of , — depends on the 

computation domain. For Example: 

— On the integer and 5ft domains: precision{{a, 6}) 44>| b—a \ . 

— On the 5ft^ domain: 



precision{{{xi,yx),{x2,V2)}) 



\xi - X 2 Y + {yi - V 2 Y- 



On the set domain: precision{{si, S 2 }) #(s2\si). 
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We overload , - - /I and define the precision of a simple interval con- 

straint c® = X C r as precision{c^) = precision{r) and the precision of a store 
S, which is stable wrt V, as precision(S) = 

By defining a computable^ bound e G 3?, we can check if the precision of 
ranges for the simple constraints in a constraint store S were reduced by a sig- 
nificant amount in the stabilisation process. If the change is large enough then 
the propagation procedure continues. Otherwise the set of simple constraints in 
the store S is considered a “good enough” solution and the procedure termi- 
nates. The function, . . /I and bound e are user or system defined for each 
computational domain. 

To use , /I and e, the operational schema needs to be extended with 

an extra test by replacing line (1) as follows: 

(1) while {S 7 ^ S') and {precision{S') — precision(S) > e) do 
As ranges in S and S' are contracted, precision(S) and precision{S') de- 
crease by more than e times the number of iterations of the loop / .. . Thus, 

there is a maximum number of possible iterations, depending on e and the initial 
stabilised constraint store S. 

(Some remarks on the precision map) 

(1) A range can be contracted whereas its precision does not decrease (i.e. 
in the real domain, a range ri = [— oo,-|-oo] can be contracted to a range C 2 = 
[0,iJr] whereas precision(ri) = precision{r 2 }). To avoid an early termination, 
an additional test to check a change on the bounds of the ranges must also be 
added to the while loop condition. 

(2) The bound e allows a direct control over the accuracy of the results^. 
For example, e = 0.0 for integers, e = 10“® for reals and e = 0.0 for sets. This 

provides the facility to obtain an , , . . , _ . when an accurate solution 

may not be computable. 

We show in the appendix that the extended operational schema has the 
following two properties. 

1 . . _ . . The procedure shown above always terminates returning a fail 

or a solution. 

2. . ... If it exists, the algorithm reaches a solution and this solution 

does not depend on the order in which constraints are chosen. 

3.8 Improving Constraint Solving on Discrete Domains 

We introduce two rules to improve our generic framework on discrete domains 
in which the. , , . , ( ) and-, , .. . ( ) of 

every value K in the domain can be computed. It is possible to eliminate the 
‘(V)’ brackets in favour of the ones using the following two ^ : 

{a, K) = {a, pre{K)] rleft 

{K,a} = [suc{K), a} rright 

^ That is, representable in the machine which is being used - the computation machine. 
[9] provided a similar idea but only over reals. 
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If _Ld and T d elements were added as fictitious bounds, we define: (1), (T d) = 
T D and (2) (J-d) = J-d- 

As an example, consider the Boolean domain with the ordering, < . 
and the constraint x 'Q \ . ). This constraint provides enough informa- 
tion to know the value of x must be , . . Thus, given . , (. ) = . , and 

(. ) =, and by applying rleft, the constraint a; C [ . , ) is trans- 
formed to a: II [ ,, ]. 

As this domain is finite, the constraints could have been solved using an enu- 
meration strategy® as is done in the existing finite domain constraint languages. 
However, by using immediate predecessors and successors, further constraint 
propagation may be generated without enumeration. 



4 Instances of Our Framework 

The framework can be used on many different domains. In this section, we 
present some examples. In the following, (Do,diDo,^ . Do^ ■ Do) de- 

notes a lattice on Dq- 



4.1 Classical Domains 

Most classical constraint domains are lattices: ( . y > ,— oo,-|-oo), 

(5J,<,, . ,, . ,-oo,-koo), ( ,<,A,V„ ,- . ) and ( ,^, 

- ,oo) are lattices under their usual orders and, < . , . , - . 

and functions return, respectively, the minimum and maximum element of 

any two elements in the computation domain. Here are examples of constraint 
intersection in the interval domain over these domains: 

(1) iC[l,8) Dd iC(0,5] = i C [1, 5] 

(2) r C [1.12,5.67) Do r C [2.34, 5.95) = r C [2.34, 5.67) 

(3) b O (false, true] C\d [false, true] = b n (false, true] 

(4) n ^ [zero, suc(suc(zero))] C\o n O [zero, suc(zero)] = n ^ [zero, suc(zero)] 

4.2 Reasoning about Sets 

(Set D, C, n, U, 0, Tset d) is a lattice over which it is possible to solve set 
constraints. For example, consider {s::' Set Integer, s C [{!}, {1, 2, 3, 4}], s C 
[{3}, {1, 2, 3, 5}]} for solving. By applying n_o twice, it is solved as follows: 

S^[tb,Ts.tIr.teg.r] S C [{ 1}, { 1 , 2, 3, 4}] = S C [{ 1}, { 1, 2, 3, 4}] 
sC [{l},{l,2,3,4}j no sC [{3}, {1,2, 3, 5}] = s □ [{1, 3}. {1, 2, 3}] 

® Possible values are assigned to the constrained variables and the constraints checked 
for consistency. 
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4.3 User Defined Domains 

Binary Strings. The domain of binary strings is the set of all sequences 
(possibly infinite) of zeros and ones together with T . The empty sequence is 
We define x y if and only if x is a prefix (finite initial substring) 

of y. Note that, in the case, x 7^ j/, glbj2*{x,y) is the largest common prefix of 
X and y (i.e.(;/&j^* (00010, 00111) = 00, (7^6^* (01, 00101) = 0) and lub-^*{x,y) 
is Then (^*, ^ j-* , , Tj-») is a lattice. This means is 

possible to define constraints on an interval lattice {D,D) (with D = xB) 
i.e. x,y '^*,x □ [001-|-TOin(7/), defines the interval of all strings which 

start with the substring 001. -I- denotes the concatenation of strings. 



Non Negative Integers Ordered by Division. Consider {Afd, diA/d) Ets the 
set of non negative integers (plus value 0) ordered by division, that is, for all 
n,m G Afd, Tn diM'd n iff 3fc G Afd such that km = n (that is, m divides n). 
This defines a partial order. Then any number) {Afd, gcd,lcm, 1,0) is a 
lattice where gcd denotes the greatest common divisor function and Icm the 
least common multiple function. Thus our framework will solve constraints on 
this domain as follows: x □ [2, 24] n_D x □ [3, 36] = x □ [6, 12]. 



Numeric Intervals We consider Interv as the domain of the numeric intervals. 
We define a :<interv b if and only if a C &. Thus glbjnterv and lubjnterv are the 
intersection and union of intervals respectively. Our framework solves constraints 
for the Interv computational domain as follows: 

iC []5,6],[2,10)] nn ic [(7,9],[4,15]] = i C [[5, 6] U (7, 9], [4, 10)] 

5 Combinations of Domains 

Our lattice-based framework allows for new computation domains to be con- 
structed from previously defined domains. 



5.1 Product of Domains 

As already observed, the direct and lexicographic products of lattices are lattices. 

As an example, consider A/q = Af U 0 the domain of naturals plus 0. Then 
A/q is a lattice under the usual ordering. Note that = 0 and T is lifted. 

(1) Let Point be the direct product domain A/q x A/q. Then, Point is a lattice. 
Note that J-pQ^nt — (l^?!^) ^^nd P point — (~^A7) ? ~^A7))- 

(2) A rectangle can be defined by two points in a plane: its lower left corner and 
its upper right corner. Let □ be the direct product domain Point x Point. Then, 
□ is a lattice. Note that Tq = ((0,0), (0,0)) and To = (T point, P Point) 
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5.2 Sum of Domains 

A lattice can be also constructed as a linear sum of other lattices. 

Definition 25. . Li,... ,Ln, . ... linear sum Li 0 

. . . © .. ._ Ls ^ . 

Ls = LiU...ULr, 

- - y - - ^Ls - ^ - - 

® y x,y € Li and x <Li y 

or X G Li, y G Lj and i < j 

glbLs - lubLs - - - . ' 

glbLg{x,y) = glbLi(x,y) and lubLs(x,y) = lubLi{x,y) if x,y £ Li 
glbLg{x,y) = X and lubLg{x,y) = y if x £ Li, y £ Lj and i < j 
glbLs(x,y) = y and lubLs(x,y) = x if x £ Li, y £ Lj and j <i 

-^Ls -^Li - - Ls Ln 

It is routine to check that the linear sum of lattices is a lattice. As an example, 
consider the lattice AtoF containing all the (uppercase) alphabetic characters 
between ‘A’ and ‘F’ with the usual alphabetical ordering and 0to9 the numeric 
characters from ‘O' to ‘9'. Then the lattice of hexadecimal digits can be defined 
as the lattice 0to9 © AtoF. 

6 Related Work 

In addition to related work already discussed earlier in the paper, there are 
two other approaches to the provision of a general framework for constraint 
satisfaction. These are described in [3] and [1]. We discuss these here. 

Bistarelli et al. [3] describe, for finite domains, a general framework based on 
a finite semiring structure (called c-semirings) . They show that c-semirings can 
also be assimilated into finite complete lattices. This framework is shown to be 
adequate for classical domains and for domains which use a level of preference 
(i.e. cost or degree). However, unlike our proposal, they require the computa- 
tional domain to be finite. Moreover, our framework does not require a level 
of confidence and, although they extended the approach of c-semirings to fi- 
nite complete lattices and, in particular, for distributive lattices, they did not 
consider, as we have done, arbitrary lattices. 

One important part of the definition of a constraint solver is the algorithm 
for constraint propagation and we have provided a simple schematic algorithm 
suitable for our constraint solving framework. In contrast, in [I], Apt focusses 
on just the algorithms and describes a generalisation for constraint propagation 
algorithms based on chaotic iterations. He shows how most of the constraint 
propagation algorithms presented in the literature can be expressed as instances 
of this general framework. Further work is needed to investigate the relationship 
between our algorithm and this framework. 
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7 Conclusions 

In this paper we have defined a theoretical framework for constraint solving on 
domains with a lattice structure. Using such a domain, we have shown how to 
construct an interval lattice which allows the use of open, semi-open, semi-closed 
and closed intervals as well as infinite intervals. Variables, constraint operators 
and indexicals for each domain provide the tools for constructing interval con- 
straints. We have shown that these constraints are a natural generalisation of the 
indexical constraints used in [4] . A schema for the operational semantics which is 
a modified form of the procedure proposed in [8] is also given and the main prop- 
erties derived from it are studied. This schema is only partially specified making 
the incorporation of efficiency optimisations easier. To ensure termination, an 
idea from [9] for controlling accuracy in the processing of disjoint intervals over 
the reals has been generalised for our interval lattices. 

Since the only requirement for our framework is that the computational do- 
main must be a lattice, new domains can be obtained from previously defined 
domains using standard combinators (such as direct product and sum) . We have 
provided examples to highlight the potential here. 

To demonstrate the feasibility of our approach we have implemented a pro- 
totype (built using CHRs [7]). This is still being improved and extended but the 
latest version may be obtained from http : / /www.lcc.uma.es/^ afdez/ generic. 
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Proofs of Properties of the Operational Schema 

(1) Termination. Let Si and 5”' denote the constraint stores S and S', respec- 

tively, at the start of the of the * -I- 1 iteration of the / .. loop. Then, Sq is 
obtained by the initial stabilisation step for C and, for * > 1, 5"^ is obtained by 
the stabilisation step (4) in the i — I’st iteration. Also, 5 'q = 0 and, for * > 1, 
S[ = Si-i, by step (3). Since both Si and S[ are stable wrt V, for each vari- 
able X G V, there are unique simple constraints G Si and G S'-. By the 
contractance property (1) of Theorem 2, c* ^ c^f, for each x G V. Thus, at the 
start of the i+ I’st iterations of the while loop, because of the monotonicity con- 
dition (ii) for the. — /I function,. — . (Si-i) > precision(Si) . Thus 
using the extended version of step (1) that allows for a precision test, if there is 
an i -I- 1 iteration, precision{Si-i) > precision{Si) -I- e. Thus, precision(So) > 
precision{Si) + i X- e. However, for some k > 0, . — (So) < k x e, so that 

the procedure must terminate after no more than k iterations of the while loop. 

(2) Correctness. Suppose the procedure terminates after k iterations. (If there 
are no iterations, then C = 0 and the result is trivial.) We denote by S- the set 
of all simple constraints in Si, 0 < i < k. Suppose S- is propagated to C- so 
that C* is the set of simple constraints obtained in step (2) of the *’th iteration 
of the procedure. We need to show that if the procedure does not fail, then S'! 
is a solution for C. We show, by induction on i that S'® is stable wrt V and 

(A) for j < i and each c® G S®, there exists cf G S® with the same constrained 
variable and c® diRo 

When * = 0, then C Sg and, trivially Cq Cq- Suppose next that i > 0. 
Then Si_i U C^_i i— > S® so that S® is stable wrt V. Moreover, by Definition 21 
for each c-_i G S®_i there exists c® G S® with the same constrained variable and 
c® c®_ 2 . However, by the induction hypothesis, if j < i — 1 and c® G C® 

there is G Sf_^ with the same constrained variable and c-_i diRo Hence, 
for each j < i and each Cj G Cj, there exists c® G S® with the same constrained 
variable and c® diRo Letting j = 0 in (A), and using the fact that in the 
initialisation of the algorithm C i— > Sq, we obtain condition (1) in Definition 24. 

We next prove that condition (2) in Definition 24 holds: 

(B) for each c"® G C"® there is c| G S^ with the same constrained variable and 

Cfe diRo c®, where c"® c®. 

In the initialisation step for the algorithm, we have C Sq. Then, in step 
(2), Sq Cf. Thus, by Definition 22, for each c"® G C"® (and hence also in ^o), 
there exists cf G Cf and c”® cf. Now, by step (4), SqU Cf i—f Si so that, 
by Definition 23, for each cf G Cf there is c® G Sf with the same constrained 
variable and cf c®. By (A) we have, for each cf G Sf there is cf G Sf with 
the same constrained variable and cf <r,^ cf. Hence (B) holds. 

By commutativity property of Hd (see Subsection 3.6), for each 0 < i < k. 
Si is independent of the order in which the constraints in Si-i UCi-i i— *■ Si were 
intersected. Thus the solution Sf does not depend on the order in which the 
constraints were chosen. 
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Abstract. We present a simple, practical algorithm for higher order 
matching in the context of automatic program transformation. Our al- 
gorithm finds more matches than the standard second order matching 
algorithm of Huet and Lang, but it has an equally simple specification, 
and it is better suited to the transformation of programs in modern pro- 
gramming languages such as Haskell or ML. The algorithm has been 
implemented as part of the MAG system for transforming functional 
programs. 



1 Background and Motivation 

1.1 Program Transformation 

Many program transformations are conveniently expressed as higher order re- 
write rules. For example, consider the well-known transformation that turns a 
tail recursive function into an imperative loop. The pattern 

. = if. 

then y 
else, (. ) 

is rewritten to the term 
, = |[var ; 

• - 5 

while ) do 



return 

]l 



Carefully consider the pattern in this rule: it involves two bound variables, 
namely , and , and three free variables, namely , , > and . . When we match 
the pattern against a concrete program, we will have to find instantiations for 
these three free variables. Finding such instantiations involves the ‘invention’ of 



A. Middeldorp, T. Sato (Eds.): FLOPS’99, LNCS 1722, pp. 209-224, 1999. 
(c) Springer- Verlag Berlin Heidelberg 1999 



210 Oege de Moor and Ganesh Sittampalam 



new function definitions. For example, here is the function that sums the digits 
of a number, in tail recursive form: 

... ( , ) = if < 10 
then + 

else , -y ( div 10, + mod 10) 

Matching this recursive definition against the above pattern should result in the 
substitution: 

( , )= <10 
'())= + 

. ( , ) = ( div 10, + mod 10) . 

This paper is concerned with an algorithm for finding such substitutions. Because 
the construction of these substitutions involves the synthesis of new functions, 
it is sometimes called higher order matching. This contrasts with ordinary first 
order matching, where we only solve for variables of base types such as Int or 
Bool. 



1.2 Higher Order Matching 

Abstracting from the particular programming language in hand, we are led to 
consider the following problem. Given A-expressions (the pattern) and (the 
term), find a substitution (f> such that 



Here equality is taken modulo renaming (a-conversion), elimination of redundant 
abstractions (/^-conversion), and substitution of arguments for parameters (/3- 
conversion). A substitution <j) that satisfies the above equation is said to be a 
match. Later on, we shall refine the notion of a match. 

Unlike ordinary first order matching, there is no canonical choice for <p. For 
example, let 



= , and = 0 . 

Possible choices for (j) include: 

, := (A . ) and := 0, 

. := (A .0), 

. := (Ay .y 0) and := (A . ), 

. := (Ay .y (y O)) and := (A . ), 



All these matches are incomparable in the sense that they are not substitution 
instances of each other. 
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1.3 Second Order Matching 

Clearly a potentially infinite set of matches is undesirable in the context of 
automatic program transformation. In a trail-blazing paper [14], Huet and Lang 
suggested restricting attention to matching of second order terms. 

This is a condition on types: a base type (for example . ) is Erst order. The 
order of a derived type is calculated by adding one to the order of the argument 
type and taking the maximum of this value and the order of the result type. So 
for example . . — is second order. The order of a term is simply the order 
of its type. 

This simple restriction guarantees that there are only a finite number of 
incomparable matches. Huet and Lang’s algorithm is the de facto standard for 
higher order matching in program transformation. In the example shown above, 
we have to give simple types to our variables to apply Huet and Lang’s algorithm, 
for example 



, : : . ^ . and : : . . 

Now the only matches found are 

, := (A . ) and := 0 , 

. := (A .0) . 

Note that we do not apply evaluation rules for constants; so for example 
, := (A . X ) and := 0 

is not a match. Of course there are other second order matches, such as 
, := (A .0) and := 1 , 

but all of these are specialisations (substitution instances) of the matches re- 
turned by Huet and Lang’s algorithm. Note that none of the other matches we 
quoted before qualifies as second order, because there the variable , has type 
( - - -)- -• 

Despite its success, Huet and Lang’s algorithm suffers from a number of 
disadvantages: 

— The restriction to second order terms is not reasonable in modern program- 
ming languages that feature functions as first-class values. For example, the 
fusion transformation [3] is routinely applied to higher order arguments: im- 
plementing that rule via Huet and Lang’s algorithm would severely limit its 
use (see Section 5 for an example). 

— Huet and Lang’s algorithm only applies to simply typed terms: it needs to be 
modified for polymorphically typed terms. For example, if we allowed type 
variables, it would be natural to assign the following types in the example 
above: 



, :: a 



. and a . 
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We now have to complicate the definition of allowable matches to prevent 
a being instantiated to function types such as . — > ... (It is not im- 
possible however: in [17], it is shown how Huet’s higher order unification 
algorithm may be adapted to polymorphic typing. The same techniques ap- 
ply to matching.) 

— The Huet and Lang algorithm requires all terms to be in 77-expanded, un- 
curried form, which means we are forced to work with typed terms. 

The purpose of this paper is to present a new matching algorithm that does 
not suffer these drawbacks. In particular, our algorithm shares the property that 
it returns a well-defined, finite set of incomparable matches. It furthermore is 
guaranteed to give at least the second order matches, but possibly more. Finally, 
its implementation is simple and efficient. 

This paper is an abridged version of a full report [10]. That full report con- 
tains detailed proofs of all major claims in this paper, and it also reports on 
computational experiments. 

2 Preliminaries and Specification 

We start by introducing some notation, and then pin down the matching problem 
that we intend to solve. Users of our algorithm (for instance those who wish to 
understand the operation of the MAG system [9]) need to know only about this 
section of the paper. 

2.1 Expressions 

An expression is a constant, a variable, a A-abstraction or an application. There 
are two types of variables: bound (“local”) variables and free (“pattern”) vari- 
ables. We shall write ,, , for constants, . for local variables, , ,, , for 

pattern variables, and use capital identifiers for expressions. Furthermore, func- 
tion applications are written , and lambda abstractions are written A . . 
As usual, application associates to the left, so that 1 2 3 = ( 1 2) 3- 

It is admittedly unattractive to make a notational distinction between local 
and pattern variables, but the alternatives (De Bruijn numbering or explicit en- 
vironments) would unduly clutter the presentation. In the same vein, we shall 
ignore all problems involving renaming and variable capture, implicitly assum- 
ing that identifiers are chosen to be fresh, or that they are renamed as needed. 
Equality is modulo renaming of bound variables. For example, we have the iden- 
tity 

(A .A. . C . )) = (A. .A. . -(.-.)). 

Besides renaming, we also consider equality modulo the elimination of su- 
perfluous arguments. The rj-conversion rule states that (A . ) can be written 

as , provided is not free in . An expression of this form is known as an 
rj-redex. We shall write 



1 — 



2 
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to indicate that i and 2 can be converted into each other by repeated appli- 
cation of 77-conversion and renaming. For example, 

(A .A. . . ) , 

but it is not the case that 

(A .A. . ) . 

Since reduction with the 77-conversion rule is guaranteed to terminate (the 
argument becomes smaller at each step), we have a total function . 
which removes all 77-redexes from its argument. It follows that 

1— 2 =- - 1 = - - 2 ■ 

The ( 3 -conversion rule states how arguments are substituted for parameters: 
(A . 1) 2 is converted to ( := 2) i- A subexpression of this form is known 
as a ( 3 -redex. The application of this rule in a left-to-right direction is known 
as ( 3 -reduction. Unlike 77-reduction, repeated application of /3-reduction is not 
guaranteed to terminate. 

An expression is said to be normal if it does not contain any 77-redex or ( 3 - 
redex as a subexpression. An expression is closed if all the variables it contains 
are bound by an enclosing A-abstraction. 

Some readers may find it surprising that we have chosen to work with un- 
typed A-expressions, instead of committing ourselves to a particular type system. 
Our response is that types could be represented explicitly in expressions (as in 
Girard’s second order A-calculus, which forms the core language of the Haskell 
compiler ghc [20]). Our algorithm can be adapted accordingly to expressions in 
which types are explicit in the syntax. However, as with the unification algo- 
rithm presented in [16], it does not depend on a particular typing discipline for 
its correctness. 

2.2 Parallel /3-Reduction 

We now introduce the operation that is the key both to the specification and 
implementation of our matching algorithm. 

The function . , performs a bottom-up sweep of an expression, applying 
/3-reduction wherever possible. Intuitively, we can think of . . as applying one 
parallel reduction step to its argument. Formally, . , is defined by 



(A . ) = A .( . , ) 

(12)= case ( of 

(A . ) - ( 

where { = . 




1 

2 
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Clearly . , always terminates, as it proceeds by recursion on the structure 
of terms. It is not quite the same, therefore, as the operation that applies (3- 
reduction exhaustively, until no more redexes remain. To appreciate the differ- 
ence, consider 

((A .A.. ( .)-)(A.. ..).)= ((A.. . 

It is worthwhile to note that our definition of . , does not coincide with 
similar notions in the literature. A more common approach is to define a parallel 
reduction step by underlining all /3-redexes in the original term, and reducing 
all underlined /3-redexes. According to that definition, we have for example 

((A . )(A . )) ((A . )(A . )) 

-(A . )(A . ) 

^A . . 

in two parallel steps. By contrast, with our definition of . , , we have 

... [((A . )(A . )) ((A . )(A . ))] = A . 

in one step. We are grateful to Mike Spivey and Zena Ariola who independently 
pointed out this subtlety. 

The operation of . , can be a little difficult to understand. In a certain sense, 
it represents an approximation of . . , - , the function that exhaustively 

applies /3-reduction: if . . , . exists then there exists some positive 

integer such that - " = , - - . However it is not always the case 

that . . , - exists, since in the untyped lambda-calculus, exhaustive (3- 

reduction is not guaranteed to terminate. 

If does not contain a A-abstraction applied to a term containing another 
A-abstraction, then . , = , . . .In particular, this condition will 

be satisfied in a typed setting by all terms which only contain subterms of second 
order or below. This claim will be further articulated in Section 5, where it is 
shown that our matching algorithm returns all second order matches. 

2.3 Substitutions 

A substitution is a total function mapping pattern variables to expressions. Sub- 
stitutions are denoted by Greek identifiers. We shall sometimes specify a sub- 
stitution by listing those assignments to variables that are not the identity. For 
instance, 

</. = {, :=( ), . :=(A. .. . )} 

makes the indicated assignments to , and . , but leaves all other variables un- 
changed. 

Substitutions are applied to expressions in the obvious manner. Composition 
of substitutions (j) and ip is defined by first applying ip and then <p: 



{(poiP) = <p{ip ) . 
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We say that one substitution (f> is more general than another substitution 'tp 
if there exists a third substitution 5 such that 

Ip = S O (j) . 

When (p is more general than ip, we write (p < ip. Intuitively, when <p < ip, the 
larger substitution ip substitutes for variables that <p leaves alone, or it makes 
more specific substitutions for the same variables. For example, with <p as above 
and Ip specified by 

iP = i :=( C )), ^ :=(A- :=C )} 

we have <p < ip because ip = 5 o (p where 

^={ :=C )}• 

If two substitutions (p and ip are equally general, they only differ by renaming: 
that is, we can find a substitution S that only renames variables so that <p = Soip. 

A substitution is said to be normal if all expressions in its range are normal, 
and closed if any variables that it changes are mapped to closed expressions. 

2.4 Rules 

A rule is a pair of expressions, written ( ^ ), where does not contain any 

? 7 -redexes, and is normal, with all variables in being local variables, i.e. they 
occur under an enclosing A-abstraction. The matching process starts off with 
closed, but because it proceeds by structural recursion it can generate new rules 
which do not have closed. In such a rule, a variable is still regarded as being 
local if it occurred under an enclosing A-abstraction in the original rule. We call 
the pattern and the term of the rule. Rules are denoted by variables , 
and . Sets of rules are denoted by , and 

The measure of a rule is a pair of numbers: the first component is the number 
of pattern variables in the pattern, and the second component is the total number 
of symbols in the pattern (where the space representing function application is 
taken to be a symbol). The measure of a set of rules is defined by pairwise 
summing of the measures of its elements. When and are sets of rules, we 
shall write <C to indicate that in the lexicographic comparison of pairs, 
the measure of is strictly less than the measure of . Note that ^ is a 
well-founded transitive relation. We can use this fact to prove termination of 
our matching algorithm, and also in an inductive proof about its result. 

A substitution (p is said to be pertinent to a rule ( ^ ) if all variables 

it changes are contained in . Similarly, a substitution is pertinent to a set of 
rules if all variables it changes are contained in the pattern of one of the rules. 
A rule ( — > ) is satisfied by a normal substitution (p if 

(0 . 

The substitution <p is then said to be a one-step match. Note that we take equality 
not only modulo renaming, but also modulo ? 7 -conversion. A normal substitution 
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satisfies a set of rules if it satisfies all elements of that set. We write 4> \~ to 
indicate that (p satisfies a rule , and also 4> \~ to indicate that p satisfies a 
set of rules 

The notion of a one-step match contrasts with that of a general match in 
that it restricts the notion of equality somewhat; a normal substitution (p is said 
to be a general match if . . . {p ) ~ . For convenience we shall refer 

to a one-step match simply as a match. 

The application of a substitution to a rule is defined by ct( ^ ) = o’ ^ 

(since is closed there is no point in applying a substitution to it). The obvious 
extension of this definition to a set of rules applies. 

2.5 Match Sets 

Let be a set of rules. A match set of is a set A4 of normal substitutions 
such that: 

— For all normal p: p\- if and only if there exists -p G A4 such that p < p. 

— For all pi,p 2 G M.' if pi < p 2 , then pi = p 2 - 

The first condition is a soundness and completeness property. The backwards 
direction is soundness; it says that all substitutions in a match set satisfy the 
rules. The forwards implication is completeness; it says that every match is 
represented. The second condition states that there are no redundant elements 
in a match set. 

For example, if = {. ■ ^ }> then 

{{ :=(A . )}, 

{ := (A .),.:=}} 

is a match set. 

Note that since 

. - - ((A .. )(A . )) = 

we have that 

{, := (A .. ), . := (A . )} 

is a general match. However since 

((A .. )(A . ))^ , 

it is not a member of the match set. 

In general, match sets are unique up to pattern variable renaming, and con- 
sequently we shall speak of the match set of a set of rules. 

In the remainder of this paper, we present an algorithm that computes match 
sets. Although it is not part of the definition, the matches returned by our 
algorithm are in fact pertinent to the relevant set of rules. Furthermore, it can 
be shown that match sets include all second order matches. 
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3 Outline of an Algorithm 

Our matching algorithm operates by progressively breaking down a set of rules 
until there are none left to solve. This section does not spell out the algorithm 
in full detail. Instead, we outline its structure, and give a specification for the 
function that provides the means of breaking down an individual rule. If 

that specification is met, the algorithm produces a match set. Then, in the next 
section, we set about deriving the function that was left unimplemented. 

3.1 Matching 

The function , . . takes a set of rules and returns a match set. It is defined 

recursively (using the notation of Haskell [4]): 



. . ( : ) = [(<^ocr) I (ct, . ) ^ 

. (a( ^ )))] 

That is, the empty set of rules has the singleton set containing the identity 
substitution as a match set. For a non-empty set of rules ( : ), we take 

the first rule and break it down into a (possibly empty) set of smaller rules 

together with a substitution a which makes equivalent to . We then 
combine the with , the remainder of the original rules, apply cr, and return 
the results of a recursive call to ... combined with a. 

The function that breaks up into smaller rules is called . Readers 

who are familiar with the logic programming paradigm will recognise it as being 
analogous to the concept of “resolution” . 

Clearly it would be advantageous to arrange the rules in such a manner that 
we first consider rules where is small, perhaps only a singleton. There 

is no particular reason why we should take the union of and by list 
concatenation: we could place ‘cheap’ rules at the front, and ‘expensive’ rules at 
the back. 

We shall not implement 

. ])] 

as yet, because that involves quite a long and tricky case analysis. Instead, we 
specify its behaviour through three properties. Let 

[(o" 0 , o),(o'l, l), ■ • ■ , (c/c, - /c)] = 

We require that 

— For all normal substitutions (\)\ 

) = \l{4>'r - iAai <4>) . 
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— For all normal substitutions 4 > and indices, and : 

i) j)^. = . 

— For each index. , is pertinent to , closed and normal. 

— The pattern variables in i are contained in the pattern variables of 

— For each index. : 

, < . 

The first of these is a soundness and completeness condition: it says that all 
relevant matches can be reached via , and that stays true to the 

original set of rules. The second condition states that should not return 

any superfluous results. The third and fourth conditions are technical require- 
ments we need to prove the non-redundancy of , ... Finally, the last con- 
dition states that we make progress by applying ; i.e. that the process of 

breaking down the set of rules will eventually terminate. 

4 Implementing resolve 

The function breaks down a rule into smaller rules, recording substitu- 

tions along the way. It does so by syntactic analysis of the shape of the argument 
rule. In all there are seven cases to consider, and these are summarised in the ta- 
ble below. The intention is that the first applicable clause is applied. The reader 
is reminded of the notational distinction we make between variables: and . 

represent local variables, and . constants, and , a pattern variable. 









[(-,[])], if =- 

[ ] , otherwise 




[( ■= I [])]) if is closed 
[ ] , otherwise 




[(-,[])], if 

[ ] , otherwise 


(A . ) - (A . ) 


[(-,[ - ])] 


(A . )- 


[(-,[ -( )])] 


( )- 


[(.,[( ^ o),( - i)])l( 01)=]^ 

[(.,[( ^ o),( - i)])l( 0, 1)- „„ ]df 

[( . , [ ^ (A . )])], fresh 




[] 



Let us now examine each of these clauses in turn. 

The first clause says that two local variables match only if they are equal. 
The second clause says that we can solve a rule ( ^ ) where the pattern 

is a pattern variable by making an appropriate substitution. Such a substitution 
can only be made, however, if does not contain any local variables occurring 
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without their enclosing A: since the original term cannot contain any pattern 
variables, any variables in must have been bound in the original term and so 
the substitution would move these variables out of scope. 

The third clause deals with matching of constants and . . These only match 
when they are equal. 

Next, we consider matching of A-abstractions (A . ) and (A . ). Here it 
is assumed that the clauses are applied modulo renaming, so that the bound 
variable on both sides is the same, namely . To match the A-abstractions is to 
match their bodies. 

Recall, however, that we took equality in the definition of matching not only 
modulo renaming, but also modulo ?7-conversion. We therefore have to cater for 
the possibility that the pattern contains a A-abstraction, but the term (which was 
assumed to be normal) does not. This is the purpose of the clause for matching 
(A . ) against a term that is not an abstraction: we simply expand to 
(A . ) and then apply the previous clause. 

The sixth clause deals with matching where the pattern is an application 
( ). This is by far the most complicated clause, and in fact the only case where 

may return a list with more than one element. It subsumes the projection 
and imitation steps of Huet’s algorithm; in essence, it attempts to write the term 

as an application in three different ways. The first and simplest way is to leave 

unchanged: of course this only gives an application if = o i (for some 
0 and i) in the first place. If that condition is satisfied, we match against 
0, and against i. 

Another way of writing as an application is to take ( o, i) from , , 

This function returns all pairs of normal expressions ( O) i) such that: 

3 : ( o = A . 

A( := i) = 

A occurs in , fresh) . 

For example, a correct implementation of , , would return 

. - ( + ) = [ (•^ • + ) ) 

(A . -I- , ) 

(A . -f , ) 

(A . , -I- ) 

(A . ,((+) )) 

(A. ,(+))]. 

We require that occurs in because otherwise the value of i would not 
matter: it could be absolutely anything. The most general choice for i would 
then be a fresh free variable — but introducing such a variable would go against 
our dictum that the term in a rule must be closed: substitutions are applied 
to the pattern, but not to the term. We therefore deal with the case of not 
occurring in separately: in that case, all we need to do is match against 
(A . ), and the argument in the pattern is ignored. 
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The final clause in the definition of says that if none of the earlier 

clauses apply, the pattern does not match the term, and the empty list is re- 
turned. 

To implement , all that is needed is an effective definition of ... 

The function . , . can in fact be implemented by abstracting subexpressions 
from , in all possible ways. This is fairly easy to program, and we omit details. 



5 Inclusion of All Second Order Matches 

As remarked earlier, our algorithm does not depend on a particular typing dis- 
cipline for its correctness. However, if we use the simply typed lambda calculus 
(and run the algorithm ignoring the type information), the algorithm does return 
all matches of second order or lower, so long as the pattern does not contain any 
/3-redexes. For the purpose of this section, we regard a substitution as a finite 
set of (variable, term) pairs. The order of a substitution (or a match) is the 
maximum of the order of the terms it contains. 

To show that our algorithm returns all matches of second order or lower, 
consider a rule — > , where does not contain any /3-redexes. (Recall that in 

a rule, the term is always normal and therefore free of /3-redexes.) Let <() be a 
match between and : 

. - - (</> )^ • 

Furthermore assume that 4> does not contain any terms of order greater than 2. 
We claim that there exists a ip in the match set of ^ such that ip < <p. The 
detailed proof can be found in [10]. 

As we stated earlier, our algorithm also returns some matches which have 
an order greater than two. We see a rather trivial example of this if we match 
. (A . -1-1) against A . -I- 1; we get the match , := A. .. , which is of type 

(.—>.)—> . — > . and therefore a third order function. 

A more practically relevant example comes from using term rewriting to 
transform functional programs. The naive quadratic time program for reversing 
a list can be expressed as a “fold” : 

= , - (A .A . ^[ ])[] 

. - (®) [] = 

, - (©) (:..)=. ©C- . (©) --) 

We can then define , . . = 4f . and transform this to a more 

efficient linear time program using the “fold fusion” law: 



, C - (®) ) 



if A - . © C ) = A - ., ( © . ) 
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Application of this law proceeds as follows. First the left-hand side is matched 
with the expanded definition of , . . , , giving the substitutions 

:=W, (©):=(A .A... ]), := [] } 

We apply this substitution to the right-hand side of the side condition, and 
rewrite it as far as possible, using the associativity of concatenation. We now 
need to solve the rule 

A - . 0 C - ) ^ A -H- ( : - . ) . 

This is where higher order matching comes in. The definition that needs to be 
generated is (0) = A .Ay .A. .y ( : - which is a third order function (since 

y is a function). We have applied our algorithm to many similar examples with 
the MAG system [9]; that paper gives a much more detailed account of the 
way higher order matching is applied in the context of program transformation. 
In particular it shows how the above transformation can be done without first 
needing to express as a fold. 

Finally, we stress that the algorithm does not find all third order matches. For 
example, when matching. , against 0, we do not get the match, := Ay .y 0,, := 
A . . As we remarked in the introduction, the set of third order matches is 
potentially infinite. 



6 Discussion 

Higher order matching allows many program transformations to be concisely ex- 
pressed as rewrite rules. Two examples of systems that have incorporated its use 
are KORSO [15] and MAG [9]. The Ergo system is based on higher order unifi- 
cation [21]. Despite the conceptual advantages offered by higher order matching, 
there also exist very successful transformation systems that do not incorporate 
its use, for example Kids [23] and APTS [19]. There are two significant objections 
to the use of higher order matching. First, even second order matching is known 
to be NP-hard [7,25], so a truly efficient implementation is out of the question. 
Second, higher order matching algorithms are restrictive, in particular in the 
typing discipline that they require. In this paper, we have demonstrated how 
that second objection can be eliminated, by giving an algorithm that operates 
on untyped terms. 

Although there is a clear specification for the set of matches the algorithm 
returns, it is sometimes not quite obvious why a particular match was not pro- 
duced. This contrasts with Huet and Lang’s algorithm, where the reason for 
failed matches is crystal clear: it takes some time to gain an intuition of what 
the function . . , does, whereas it is easy to see whether a function is second 
order or not. In our experience with the MAG system [9] there seem to be a 
handful of techniques to deal with failed matches (for instance ‘raising’ a rule 
by introducing explicit abstractions), so we feel that the disadvantage is not too 



serious. 
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There is a wealth of related work on higher order matching and unification 
[5,7,11,12,13,16,18,24,25], to name just a few. One important concept identified 
in some of these works (in particular [16,18]) is that of a restricted notion of 
higher order pattern. To wit, a restricted pattern is a normal term where ev- 
ery occurrence of a free function variable is applied to a list of distinct local 
variables, and nothing else. For such restricted patterns, much simpler and more 
efficient matching and unification algorithms are possible. Our algorithm returns 
all higher order matches for rules where the pattern satisfies the above restric- 
tion; in fact there is at most one such match. We have not yet investigated the 
efficiency of our algorithm in this important special case. 

There are a number of specialised pattern languages for the purpose of pro- 
gram inspection and transformation e.g. [1,2,8]. Often these do not include higher 
order patterns, and it would be interesting to see what primitives suggested in 
these languages can be profitably combined with higher order matching. 

It remains to be seen whether we can overcome the second objection to higher 
order matching in program transformation, namely its inherent inefficiency. We 
are currently investigating to what extent techniques for fast implementation of 
first order matching [6] can be applied here. Preliminary experiments show that 
the efficiency of our algorithm is comparable to that of the algorithm by Huet 
and Lang. 
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Abstract. We address the problem of finding the common generalisa- 
tion of a set of Haskell function definitions so that each function can 
be defined by partial application of the generalisation. By analogy with 
unification, which derives the most general common specialisation of two 
terms, we aim to infer the least general common generalisation. This 
problem has a unique solution in a first-order setting, but not in a 
higher-order language. We define a smallest minimal common generali- 
sation which is unique and consider how it might be used for automated 
program improvement. The same function can have many dehnitions; 
we risk over-generalisation if equality is not recognised. A normalising 
rewrite system is used before generalisation, so many equivalent dehni- 
tions become identical. The generalisation system we describe has been 
implemented in Haskell. 



1 Introduction 

In functional programming we often use general-purpose functions from a library 
to make our definitions simpler and more concise. Conversely, if we recognise a 
common evaluation pattern in our own definitions we may wish to add a new 
general-purpose library function to realise that pattern. This paper is about the 
automatic creation of general functions. Given a set of Haskell function defini- 
tions we find their common generalisation g and a set of embedding equations 
which redefine each function as a partial application of g. 



omnivores [] = [] 

omnivores (a: as) = if eatsMeat a kk eatsVeg a then a:oas else oas 
where oas = omnivores as 

teens [] = [] 

teens (n:ns) = if 13 <= n kk 19 >= n then n:tns else tns 
where tns = teens ns 

We define omnivores to select animals which eat meat and vegetables from 
a list. It looks similar to teens which finds all numbers in its argument list in 
the range 13-19. We can define a new function dFilter by keeping the common 
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parts of omnivores and teens and introducing new variables p and q where 
they differ. Now omnivores and teens can be given simpler definitions as partial 
applications of dFilter. 

dFilter p q [] = [] 

dFilter p q (x:xs) = if p x && q x then x;dfxs else dfxs 

where dfxs = dFilter p q xs 
omnivores = dFilter eatsVeg eatsMeat 
teens = dFilter (19 >=) (13 <=) 

Generalisation is a routine part of programming, the original motivation for 
this work was to provide a tool to assist programmers. Other possible applica- 
tions include selective generalisation in optimising compilers. This work raises 
qualitative issues like which generalisation is most useful, as well as quantitative 
ones such as which generalisation gives the most compact code. 

We want a generalisation that is minimal in some sense. In first-order logic a 
. y y . - . _ . is found by , . - _ . - ) [13,12]. 

In a higher-order functional setting we can say g is less general than g' if there 
is a partial application of g' specialising it to 5. The problem with this is g may 
also specialise to g' , neither is less general, let alone least general. 

We could use the prelude function filter as the generalisation of 
omnivores and teens. It is less general, filter = dFilter (const True); it 
is also more general, dFilter p q = filter (\x -> p x && q x). 

filter p [] = [] 

filter p (x:xs) = if p x then x:xs’ else xs’ 
where xs ’ = filter p xs 

omnivores = filter (\x -> eatsMeat x && eatsVeg x) 
teens = filter (\x -> 13 <= x kk 19 >= x) 

1.1 Structure of the Paper 

A Core language in which generalisations are inferred is defined in Sect. 2. This 
restricted syntax makes equivalences easier to identify, so there is less risk of 
over-generalisation. Further, even within the core language, distinct definitions 
can be recognised as equivalent by normalisation. Sect. 3 explains the rewrite 
system used for this purpose and its properties. In Sect. 4 the idea of a smallest 
minimal common generalisation is developed: Its inference rules are given and its 
properties are discussed. In Sect. 5 the generalisations produced are evaluated 
and potential applications for automated generalisation are considered. Related 
work and extensions to generalisation are discussed in Sect. 6. 

2 The Core Language 

Core is a subset of Haskell used for generalisation to reduce the number of ways 
a function can be written. It is similar to Haskell Kernel [5] but lambda or 
let abstractions are not allowed in arbitrary positions and features to simplify 
generalisation are included. 
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d € Def 


:= f Xa - ■ ■ xi = e where £ 


C G Locs 


II 

d 

II 


e £ Exp 


~ k \ V 




1 e e 




case e of{pi ^ Ci}[; Cj 


u,v £ Var 


■— fi 1 fi,j 




\r\Vi 

\ Xi\a 


p £ Pat 


:= kci - ■ ■ Ca 



function definition 
local function definitions 
constructor, variable 
application 
e] case expression 

constant, local function 
recursive call, local function parameter 
function parameter, pattern variable 
constructor pattern 



Fig. 1. Core language grammar 



2.1 Core Language Definition 

Core is defined in Fig. 1. Function definitions include . . This 

allows partial applications, local recursion and higher-order substitutions to be 
written, whilst simplifying local definition naming and positioning. 

- with simple patterns are included, as in Haskell Kernel. 
They include a set of constructor-pattern alternatives possibly followed by a 
default alternative with a variable pattern. This simplifies matters because the 
ordering of constructor alternatives is immaterial. To convert a standard case 
expression with a sequence of alternatives we remove any alternatives that can 
never match. For example, (case a; of (1 — > y, 1 ^ z, u ^ u, 2 ^ w)) becomes 
(case a; of {1 —*■?/}; u ^ m). 

A sequence of zero or more expressions (ei • • • e„) may be written e. A set of 
constructor-pattern alternatives may be abbreviated A and all the alternatives 
of a case as . So {f x = case fc e of {fc c ^ e} U A) is a schematic function 
definition, the body is a case expression with constructor k applied to some 
expressions as its subject and a set of constructor-pattern alternatives including 
and whose alternatives include one with constructor k binding the variables c as 
its pattern, there may be any number of other alternatives. 

of /i are named r: They will become calls of the gen- 
eralisation. Other free variables, including mutual recursions, are not affected 
by generalisation. ... y of function-bound variables makes adding 

arguments during generalisation simpler: They are added to the start of the ar- 
gument list so the original can be recreated by partial application. Different kinds 
of bound variable are clearly distinguished. Case-bound variables and local defi- 
nitions are uniquely named in a script. Function and local definition parameters 
are named by position. 

The Core translation of omnivores has case expressions instead of 
if-expressions and multiple equations. The variable naming and list notation are 
standardised. The lifted local definition requires the parameter yi. The recursive 
call is replaced by r. 
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size{k) = 0 
size{v) — 0 

size{ei Sr) ~ 1 + size(ei) + size{er) 

n 

size{case e of a) = 1 + size{e) + ^ (1 + size(ai)) + size{a) 

i = l 

size{p — > e) = 1 + size{p) + size{e) 
size{fi,j yi ■ ■ ■ Pa = e)) = 1 + a + size(e) 

n 

size{f Xa ■ ■ ■ xi = e where — 1 + a + size{e) + (1 + size{li)) 

i = l 
n 

stze{{di}Y^i) = ^(1 + size{di)) 

i = l 



constructor 

variable 

application 

case 

alternative 
local definition 

definition 

definitions 



Fig. 2. Expression and definition sizes 



- x\ = case xi of 

f [] ^ []; (0 Cl C2 ^ case (&&) ( .. - ci) ( .. . ci) of 1 

\ {False ^ Zip C2, True ^ (:) Cl (/i,i C2)} J 

where {/14 yi = r yi} 

2.2 Expression and Definition Size 

To provide an abstract measure of the complexity of an expression or definition, 
its - . is defined in Fig. 2 as the number of internal nodes needed to represent 
it as a binary tree. This is useful for comparing generalisations and deciding if 
generalisation is worthwhile. 

2.3 Equality 

Core variable naming ensures that corresponding function arguments and recur- 
sive calls are identical. Case-bound variables and local functions are uniquely 
named across all definitions, Ca =a Cb means Ca and Cb are , , , , . 

- y of case-bound variables. We also assume that where there is no default 
alternative, (case e of A) =„ (case eof A;v ^ ). We need to consider 

partial equality of case expressions so we define , , . , y , 

(case eof AL> A']v ^ e') = (case e of A; u — > case u of A'; v e'), as Cq =ac e&. 

For example, (case xi of (1 ^ X2 , 2 ^ X3}\v — > ) =ac (case x\ of (2 ^ 

X3}',u — > case M of {1 ^ 3^2}). Equality by definition or . . , , ... is 

written Ca = eb- 

3 Function Normalisation 

There are still many ways to define a function in Core. Showing equivalence is an 
undecidable problem but we can improve the chances of equivalent expressions 
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having the same definition - and therefore becoming part of the generalisation 
- by using a normalising rewrite system to eliminate differences of style. 

3.1 Normalisation Rules 

Normalisation makes distinct definitions identical if they are equal under a set 
of equivalences. We use local equivalences - no knowledge of free variables is 
assumed. Obvious extensions to this scheme could make use of axioms about 
primitive functions or established prelude function definitions. 

The rules (see Appendix) are based on (3,rj and Case reduction [2,5], they 
are divided into two systems. A rule I r rewrites a definition (or expression) 
matching I to r. Side-conditions are used to constrain the definitions that may 
match 1. 

_ , in-lines non-recursive local definitions to ex- 

pose common structure, partial applications are saturated if possible or spe- 
cialised ( , . pi /34). Eta-reduction ( , . ?yl, 772 ) is applied to local definitions, 

it is defined inductively because an outermost application can be disguised as a 
case by the equivalence used in rule Case6. Case expressions are reduced to a spe- 
cialisation of an alternative right-hand side if possible; if not, they are rewritten 
into a normal form where dead subexpressions can be identified. The merging 
and floating rules improve the likelihood of similar expressions being kept in the 
generalisation ( , ). 

_ , cleans up the result of the first by removing 

dead local definitions, 77-reducing function definitions and merging case alterna- 
tives where possible. 

The normal forms of omnivores and teens are shown here. Local 
definition in-lining and removal have been applied. 

- , xi = case xi of 

H] ^ [],(:) Cl C 2 ^ case (&&) ( . - ci) ( . . ci) of 

( {False — > r C 2 , True ^ (:) ci (r C 2 )} 

. xi = case xi of 

f[] ^ []i (0 C 3 C4 ^ case (&&) ((<) 13 C3) ((>) 19 C3) of 1 
{ (False — > r C4, True ^ (:) C3 (r C4)} j 

3.2 Properties of Normalisation 

Proposition 1. . _ . . . 

Termination is demonstrated using a well-founded ordering over the expres- 
sions. The right-hand side of each rule is lower in the ordering than the left-hand 
side. The ordering is monotonic - reducing a subexpression reduces its context. 
A simplification ordering [3] proves termination where rules remove arguments, 
definitions or alternatives. For the in-lining rules, replacing a (non-recursive) 
function by its definition is strictly reducing in the ordering, this follows from 
the typed lambda calculus strong normalisation property. 
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Proposition 2. . _ . , 

As normalisation is terminating, it is sufficient to show confluence [4]: 
For all critical pairs of rules (those with overlapping left-hand sides), the result of 
applying either rule first has a common descendant. For example, specialisation 
and in-lining overlap. Full in-lining gives the same result as partial specialisation 
followed by in-lining, once the specialisation is removed. 

4 Generalisation by Co-unification 

In this section we define a unique minimal generalisation of a set of Core function 
definitions using a form of , . - _ . . We consider why the usual method for 

comparing generality is inadequate, then by restricting the kind of generalisation 
we are willing to allow we develop an alternative definition of a minimum that 
meets our expectations and is equivalent to the usual minimum in the first 
order case. This idea is extended to full Core by defining a smallest minimal 
generalisation. 

Definition 1. . . . 

. . . E , ... h > 0 y h . 

.-- [•] - - - .... - V.h 

- - - [Cl, . . . , Ch\ ^ ■ -- - ■ -y-- , - . - 

. v®v 



((&&) ((<) 13 Cl) ((>) 19 Cl)) = ((&&) ([•] Cl) ([•] Ci))[(<) 13, (>) 19] 

= ((&&)([•] ci)([.j ci))[(<)13]©[(>) 19] 

Definition 2. . _ 

y. . . . . .m, . _ . . 

' - {,fi -- - - y ' y 

- y m , , - / -- - 

Cg, {fi = ge')) 

4.1 Minimal Common Generalisation (MCG) 

The generality of generalisations in first-order logic is compared using the re- 
stricted instantiation preorder [1]. In the first-order case there is always a unique 
minimum common generalisation of a set of terms which is least in this order- 
ing. The ordering can be adapted to a functional setting to give a generalisation 
ordering that places g' above g when g' can be specialised to g. 

Definition 3. . _ . . y 

(5 • • • , (/z ■ • •)) < ( 5 ' ■ • • , (/r ■ ■)) ^h-{hx = g't) ^h = g 



{fi^i = 6i)™ 1 

- g - .... 

■ h- ■ .9 
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The functions (/i = 1 + 2, /2 = 3 + 4) can be generalised to 
{g'x = a:, (/i = g'(l + 2),/2 = 5'(3+4))) or ( 5 ?/z = y+z,(/i = 5l2,/2 = g34)). 
We can define hy z = g'{y + z) and use h in place of g, therefore g < g' . 

This ordering is consistent with the intuition that g' is more general than 
g if g' has a variable where g has some other expression. In first-order logic it 
can be formalised using the lattice structure of first-order terms [10], there is 
always a unique least generalisation which is the least upper bound of the terms. 
Analogously, we can define a least-general generalisation, this ought to be the 
one we choose to infer - intuitively it is just general enough. 

Definition 4. . y y . _ 

ig-’-Afi---))- - > ' - - y - - F., , 

- . - (-?'•••,(/'•••» y F (/'•••)) 

In a higher-order functional setting, where we can apply the generalisation 
to functions, there is no unique least-general generalisation. We saw this in the 
introduction, filter and dFilter are instances of each other so neither is a 
unique minimum. We develop a minimal common generalisation (MCG ) for a 
first-order subset of Core where there are no local functions. Generalisations are 
restricted so that the specialised generalisation must be. . . _ to the original 
definitions - not merely equal. A unique minimum is defined using the idea that 
all parts common to the original definitions should be kept by the generalisation 
(and therefore not substituted by the embedding equations). We also need to 
rule out generalisations that include unneccesary arguments. 

Definition 5. . , y . _ 

(gx = £'[a;i, . . . ,a:„], (/i = 5 ep • • -en,)). . , y . _ , . . 

~ - {fiXi — e2)-_,Vi*T/[ei^,..., — ac 



Definition 6. 

- - y - -y (e.)-- - , - - 

- y - - - - {E, {Vi}) . , . .. . =ac EVi 

- - - . --- ([^(N)) 

When all the expressions are equal up to bound-variable renaming they are 
the common part (1). When they are all applications 2), the common part is 
formed as the application of the left common part to the right common part. 
When they are all case expressions and there are some common constructor 
patterns (3), the common part is a case expression with the common part of the 
subject expressions as its subject and the common part of the alternatives as its 
alternatives. In any other case the expressions have nothing in common and a 
single hole is returned (4). 

The common part of a set of case alternatives is found by , '. If all the 
alternatives include a common constructor pattern then a new alternative is 
formed by finding the common part of the corresponding right-hand sides. A 
substitution cj) is needed to make the corresponding pattern-bound variables 
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cp (ei) = (e, ([])), if Vi • e =„ a 
cp {el^ Cvi) = {El Er, {Vi^ © Vn)) 

cp (case Csi of ASi) = (case E^ of AS, {Vs^ © VASt)), 7 ^ (0; v ^ [•]) 

cp (d) = ([•], ([ci])), otherwise 

where {Ei, {V^)) = cp (e;,), {Er, {Vr,)) = cp {cn) 

{Es, {6s,)) = cp {cs,), {AS, (Vas,)) = cp' {ASi) 

cp' {Ai',Vi a) 

_ ( {{P ^ Ep} U A;v ^ E, {Vp^ © VAi)),if Vi • 3{pi CpJ & Ai ■ p = pitp 
\ (0;n ^ E', (T4i)), otherwise 

where {Ep, {Vp^}) = cp {cp^cf)} 

{A;v E,{VAi)) = cp' {Ai - {pi epj;wi ^ a) 

Ijpi nr _ f cp (ei[u/ui]), if Vi • Ai = 0 
' ’ ' y ([•], (rhsi)), otherwise 

pj^g. rr / Ci[w/wi],if Ai = 0 

\ case M of Ai; Vi ^ Ci, otherwise 



( 1 ) 

( 2 ) 

(3) 

(4) 



Fig. 3. Common part of a set of expressions 



identical. When there are no common constructor patterns, a variable pattern 
alternative is returned. Its right-hand side is the common part of the expressions 
(ci) if there are no constructor-pattern alternatives left, otherwise it is a hole 
and . i is an expression built from the remaining alternatives. 

Here we find the common part of two case expressions. The common 
pattern 0 is kept, the common part of False and 0 is a hole. There are no more 
common patterns so a new variable-pattern alternative is given with a hole as its 
right-hand side. The first equation is reconstructed by putting a case expression 
containing the remaining alternative in the second hole, the second equation just 
puts the expression {X 2 /X 1 ) in the second hole. 

, (case x\ of {0 ^ False, 1 — > True}, case x\ of {0 — > 0}; c\ X 2 /X 1 ) = 
((case xi of {0 ^ [•]}; C 2 ^ [•]), ([False, case C 2 of {1 — > True}], [0, X 2 /X 1 ])) 

We formalise generalisation by co-unification of a set of function definitions 
by equilizing their arities then taking the common part of their bodies. The 
generalisation is formed by dropping a new variable into each hole. For the 
generalisation to be minimal we need to use the same variable in two holes that 
are always filled by the same expression for each function. We achieve this by 
labelling the holes, labelling repeatedly applies , y- ^ which gives two holes the 
same label if they always have the same substitution. If the set of vectors {Vi) in 
the common part are viewed as a matrix with a column for each function, merging 
eliminates any repeated rows. For example, . ((&&) ([•] [•]) ([•] [•]), ([((<) 13), ci, 

((>) 19), Cl])) = ((&&) ([.]i H 2 ) ([-]3 H 2 ), ({((<) 13)/[-]l,Ci/[-]2,((>) 19)/[-]3})). 
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Definition 7. . . . 

- . . E , . n . . h . _ . [-]l 

■ - - - - . - . . -- y - . . . . {ei/[-]i, . . . , en/[']n} 



Definition 8. 



where , [-J/j], ({ = '•'merge 

{E,{{ej^/[-]j'\yj Oi)) Emerge {E{[-]k / , {Oi)) ,'liyi ■ =a^i([']fc) 



Definition 9. . . ^ _ MCG 

- - « - - (ff -6^{a;j7[-]j}”=i, (/i = 5 eii • MCG 

. {f^^^ = ei). . („ (ci)) = Vj- „ (e^J = 

([•],([et.])) 

Propositions. . MCG- .. . ^ ^ _ 

In the first-order case - where we can substitute expressions but not func- 
tions - the arity of a simple generalisation can be reduced by merging or the 
expressions substituted for the same variable by the embedding equations have 
a common part iff there is a less general simple generalisation. 



4.2 Smallest MCG of Higher-Order Functions 

Extending the MCG definition to full Core - where local definitions may have pa- 
rameters (necessary for substituting expressions that include variables) - allows 
us to compare generalisations that are indistinguishable under the generalisation 
ordering. For example, filter is not an MCG of omnivores and teens because 
the embedding equations have a common part - both apply kk - dFilter is an 
MCG . An MCG is not unique. We may need to substitute functions so the holes 
will be filled with expressions of the form (xj vj) and the embedding equations 
will substitute a function of the variables vJ for Xj. Because the parameters to 
Xj may be reordered or added to without compromising the minimality of the 
context we define a , .MCG - the generalisation we choose to infer. 

Definition 10. . . . ^ _ SMCG 

SMCG , (/i Xi = Ci where Ci) . .. . . ^ ^ _ 

... . {gx = E{xj 77/[-]j}”=i, ifi = gfu--- fn, where {fj, vJ = 

/ . Vi • {E{ej^/[■]j}J^J^ =ctc Ci) 

Proposition 4. . SMCG- - - - - ^ 
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smcg{fi Xa^ - ■ -xi = a where Ci) = (g Xa+n ■ ■ ■ xi = eg[g Xa+n ■ ■ ■ Xa+i/r], (5) 



(/i = (r J_a • • • -Lai+i where {fij Vj = ej,}"^i)[g fi,„ ■ ■ ■ fi,i/r])) 



where 



a — max(ai), (e'i where £;) = (d where jCi)[r Xa - ■ ■ Xai+i/r] 

i 



(6) 



{E, (Oi)) = label(cp (e')) 

(£; where Ui Ci,{9i),9) =^cpb (-E' where </)) 

V] = sort{Ui{xk,yk,Ck, fk,i e FV{ejf))) 
eg = {E’ where C){xa+j vJ/[-]j}"^i 



(7) 

(8) 
(9) 

(10) 



(£; where £, ({/i,h /[■]*:} U6»i),cji) 

^ / ((-B where r)[//[-]fe],(6'i),<(>), if {f / Ui,ii)) ^ 

cpb I (6»"),0u {/„em/(/i,ji)}), otherwise 

where {fij^ yi ■ ■ ■ Va = Ci} C C, {E', (6»')) = label{cp {ei)) 

{E where jC U {/„e™ yi---ya = E'}, {9i U 0')) =^merge {E" , {9")) 



The SMCG is uniquely determined up to the ordering and naming of new 
variables Xj and the ordering of their parameters vJ. 

SMCG inference (Fig. 4) is defined in terms of the common part and redun- 
dancy removal. First any recursive calls are modified to assumes all the functions 
have arity a - the maximum of their arities (6). Then the common part of the 
defining equations is found (7), the labelled common part of the bodies is found 
by . , (8) which creates a new local definition from any local definitions with 
the same arity which are called at the same position. This labelled context is 
turned into the generalisation body (10) by putting a new variable applied to 
any variables needed by the corresponding substitutions (9). Any recursive calls 
in g must include these new variables; the embedding equations substitute a 
function for each new variable, recursive calls become calls of g (5). 



The SMCG of normalised . . and . - , . . is g. It is a version 



Fig. 4. SMCG inference rules 



of dFilter with the local definition in-lined. 



g X 3 X 2 xi = case xi of 



{ 



[] ^ [],(:) C 5 C 6 ^ case (&&) (x 2 C 5 ) (xs C 5 ) c 
{False g X 3 X 2 cq, True 

- =9 - ^ - - , - = 5 ((>) : 




9 {{>) 19)((<)13) 



4.3 Properties of SMCG Inference 
Propositions. SMCG- , - 
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By induction on the , rules, the instantiated context yields the original 
expression. The treatment of recursive calls in the . , y rule ensures the gener- 
alisation process is sound. Merging may cause type errors though. The system 
is not currently safe in this respect, hole merging only when type-safe is left as 
further work. 

Proposition 6. SMCG- , . - . 

The presence of local definitions means that the generalisation will not neces- 
sarily be smaller than the original definitions as in first-order logic [12]. Without 
local definitions the complexity of the rules is quadratic in the size of the input, 
owing to the union and sorting operations needed. Where local definition calls 
are in the common part, new local definitions are formed from their definitions. 
Termination is demonstrated by induction on the number of local definition calls 
in the common part. 

5 Evaluation 

The generalisation system is capable of > - > / - , . , - from 

examples, we have already seen an example of this with dFilter. We are also 
able to generate well-known prelude functions from instances, e.g. f oldr from list 
summation and multiplication functions. The SMCG might not always be the 
generalisation a programmer would like though, even with some normalisation, 
co-unification is susceptible to differences in style. 



omnivores [] = [] 

omnivores (a: as) = if eatsMeat a && eatsVeg a then a:oas else oas 
where oas = omnivores as 

teens [] = [] 

teens (n:ns) = if n >= 13 && 19 >= n then n:tns else tns 
where tns = teens ns 

The SMGG of these definitions is different to dFilter because a and n occur 
at different positions, it seems more difficult to use than dFilter did. 

g q f h [] = [] 

g q f h (x:xs) = if (h x (f x) && q x) 

then x:g q f h xs else g q f h xs 
omnivores = g eatsVeg id (const eatsMeat) 
teens = g ((>=) 19) (const 13) (>=) 

Automated generalisation is a - , way of creating new functions, but 
programmers may be less interested in strictly minimal functions like g in the 
previous example and prefer generalisations defined in terms of functions they are 
familiar with. Indeed, as programs are usually written assuming certain primitive 
and library functions, the generalisations should be much better if the generaliser 
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could work from the same background knowledge. A generalisation system incor- 
porating more heuristics and rewriting its output in terms of prelude functions 
may be more appealing in this application. 

If using an instance of a general-purpose function produces smaller compiled 
code then automatic generalisation can be used for . . . y . , , _ . . 

_ . As a compiler optimisation, our worries about the legibility of the output 

would not be an issue. Certainly introducing new library functions can make pro- 
grams more compact. For example, the abstract size of omnivores and teens 
is 44, the size of their SMCG and the embedding equations is 37. Another set 
of tests we did looked at finding generalisations of groups of standard prelude 
function definitions. 



sinh X = (exp x - exp (-x)) / 2; cosh x = (exp x + exp (-x)) / 2 

These definitions are taken from the Haskell 1.4 standard prelude. Their 
abstract size is 20. The size of their SMCG (below) is 17. In a simple application 
compiled with the Glasgow Haskell Compiler on our machine, the object code 
size using the original definitions was 332 bytes larger than when the generalised 
definitions were used. With full optimisation on, the saving was 4,888 bytes. 
Note that a simple common subexpression analysis could not save any space in 
this example. 

g x2 xl = x2 (exp xl) (exp (-xl)) / 2 
sinh = g (-) ; cosh = g (+) 

The ad-hoc construction of existing libraries suggests they may contain op- 
portunities for space and structural improvement by generalisation, our tests 
reinforce this view. Alternatively, libraries could be . - . for particular appli- 

cations. The difficulty in large programs is choosing which functions to generalise. 
The module system may be helpful in that functions working over the same data 
type are likely to have something in common. Functions with similar types are 
also likely to have some common content. 

If an interactive editor could > - - . of existing library functions 

(by generalisation the instance with suitable functions to find one that allows 
the instance to be defined as a simple embedding), it could give useful hints to 
trainee programmers. - - > - , . _ by this method would be more 

reliable than simply using the polymorphic type, as in [14]. Again, we have the 
problem of selecting which library functions to try. 



6 Related Work and Further Work 

Generalisation in first-order logic was investigated by Reynolds and Plotkin 
[13,12] who defined a unique . y y - _ of any two terms, ob- 
tained by , - - . Generalisation is the basis for , y , . .. .. [16] 

where rules are inferred from examples. Hagiya [7] uses higher-order and semantic 
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unification to synthesize programs by generalising first-order terms. A .. y. 

. _ . algorithm is given by Huet [8] which finds a higher-order unifier 

whenever one exists. A common generalisation always exists, SMCG inference 
provides a meaningful way to choose a generalisation. 

There are many possible improvements to the generalisation system. Recog- 
nising more equivalences and using additional rewriting to suit the application 
have been mentioned. A normal form for mutually recursive local definitions 
would also be useful; , _ , , _ could be used to specialise such defi- 

nitions, the call graph could be normalised by selective inlining. 

Type safety of generalisation should be investigated so we can guarantee that 
the type of an embedding equation is the same as the type of the function it 
replaces. Another potential problem with the current system is that normalisa- 
tion can change the complexity of definitions. Some other useful improvements 
are outlines below, they all have the drawback of not giving a unique minimal 
generalisation. 



- . y y . - . - . the MCG definition could be interpreted to mean there 

should be as few new variables as possible. The SMGG is a first approximation to 
this true minimum. We only replace two new variables by one if one is redundant. 
In general, one variable will suffice where their substitutions can be co-unified. 
Repeating co-unification will give a higher approximation to the minimum. In 
an untyped language we can always find a generalisation that only needs one 
new variable, in the typed case we are more restricted. 

mean x y = (x + y) / 2; avg x y = (y + x) / 2 
gfhxy = (hxy + fxy) / 2 

mean = g (\x y -> x) (\x y -> y) ; avg = g (\x y -> y) (\x y -> x) 

By co-unifying the expressions substituted for x3 and x4 in the SMCG of 
mean and avg we get the generalisation below which needs only one new variable. 

gfxy=(fxy + fyx)/2 

mean = g (\x y -> x) ; avg = g (\x y -> y) 

- - . , could give better generalisations. In the pre- 

vious example we could recognise that mean. . avg modulo commutativity. Equal- 
ity modulo theory E cannot always be shown by normalisation, so the general- 
isation rules need extending, though where possible normalisation appears to 
be a better solution. Unification modulo E has been studied for many theo- 
ries. Stickel’s algorithm for associative-commutative functions is a good example 
[15]. Generalisation relative to a background theory for atomic formulas has also 
been studied [II]. Baader [1] defines E-generalisation in the same framework as 
E-unification. 

- y , y , , - to be more than passive suppliers of substi- 

tutions could give smaller generalisations. Yet another way to generalise mean 
and avg is to swap the arguments and define mean x y = avg y x. 
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- , . (for which embedding equations substitute _L) could be 

used to substitute expressions. This idea is used by Furtado [6] where the co- 
unification of the terms {x,t) is {x, {{x/x}, {t/x})). 

Generalisation is a powerful transformation. Using ideas about program im- 
provement, such as size reduction, seems a suitable way to utilise some of its 
untapped potential in a controlled way. 
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Appendix: Normalisation Rules 



Normalisation system 1 rules based on / 3 , vy-reduction 

. (e)= {XF.FU{f\fGFJy=e',feFVie')}){FV{e)) 

Assume f y[ - • • y^r = e' where /' ^ . . (e') for rules (il to / 34 . 

/31 (saturated application inlining) 

{f ei---ei) — >01 {e'[ei/y[,...,e'^/y'^,] e(o/+i) • • • e; ) 

/ 32 (arity- raising base case) 

{fv = fe) — >/32 {fvu = e),ifl<a'A{feu) — >0i (e) 

/ 33 (arity-raising induction step) 

{fv = case e of {pi e*}; c ^ eo ) — >03 {fvu = case e of {pi e'J; c ^ e'o ) 
if • ( / tJ = ej ) — >02,03 {fvu=ej)Ak0^j (e), = et u) 

/ 34 (partial application specialisation) 

( / V = E[f ei • • • ez] ) — >^34 {fv = E[J” mi • • • Ufe] ) , if / < a' 

where (tti, ...,Uk)= - (2/0 G G FV({ei, . . . , 6 ;})) 

/" ui---uk yi+i ■■■ya = e'[ei/yi, ei/yi] 

77! (eta reduction base case) 

(fuv = ev) — >^i ( / M = e ) , if u ^ FV (e) 
r;2(eta reduction induction step) 

[fuv = case e of {pi Cj}; c ^ Cq ) — >,,2 {fu = case e of {pi e'}; c ^ Cq ) 
if V ^ FV (e) A Vj • ( / M u = Cj ) — ( / « = e) ) 



Normalisation system 1 rules based on case reduction 
Casel (variable pattern case reduction) 

(caseesof0;u^ e) — >Casei (e[es/w]) 

Case2(case variable specialisation) 

(case Cs of A; u ^ e) — >case 2 (case Cg oi A] v ^ e[es/v ] ) 

Case3(case merging) 

(case eg of A; u — > case Cg of {ki cl Ci}; m ^ e) 

^Case3 ( (case Cg of A U {ki ^ | ki ^ A}; u e)[eg/v ] ) 

Case4(pattern matching case reduction) 

ej[e/cj], if fc = kj 



(case fc eof [h Ci e*}; v ^ e) — >case 4 



e[k e/w] 



if Vi, k ^ ki 



Case5 (floating case out of case) 

(case (case Cg of {pi ed; w ^ e) of ) 

— >Case 5 (case 6g of {pi case of }',v^ case e of ) 

Case6(floating apply into case) 

( (case 6g of [pi 6i}; 7 ; ^ e) e) — >Case6 (case Cg of {pi Ci e}; w ^ e e) 

Case7(dead alternative elimination) 

( case Cg of {/c V ^ e} U A; u ^ if [case e'g of {ku ^ e"} U A'; a] ) 

— >Case 7 (case 6g of {/c V ^ c} U A; V — > if [case e( of A'; a]) , if Cg =a e'g 
CaseS (repeated computation elimination) 

(case eg of {p ^ e} U A; a) — >CaseS (case Cg of {p e[p/eg]} U A; a) 
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Case 9 (variable pattern simplification) 

/ r A \ f case Csoi Au {kc 

( case CsOt A; V ^ e) — >Case 9 ^ 



^ case 6s of A, if [/ = 0 
where U = {constructors k of type r(es) | {kc^e)^A} 



e[k c/v]}, iiU = {k} 



Normalisation system 2 rules 
/35(local definition elimination) 

(ewhere£) — >^5 ( e where {(/•••) G | / G . . (e)}) 

CaselO(redundant alternative elimination) 

( case 6s of Ip — > e} U A; ^ e' ) 

J case 6s oi A',v ^ e', if e =„ e' A A 0 
^CaselO ^ ^ g}j ^ ^ g'^ if 6 =„ c' A A = 0 

where po is the least constructor of type r(es) 
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Abstract. Lambda-lifting and lambda-dropping respectively transform 
a block-structured functional program into recursive equations and vice 
versa. Lambda-lifting was developed in the early 80’s, whereas lambda- 
dropping is more recent. Both are split into an analysis and a transfor- 
mation. Published work, however, has only concentrated on the analysis 
parts. We focus here on the transformation parts and more precisely on 
their correctness, which appears never to have been proven. To this end, 
we define extensional versions of lambda-lifting and lambda-dropping 
and establish their correctness with respect to a least fixed-point seman- 
tics. 



1 Introduction and Motivation 

If procedural programming languages are out of the Turing tar pit today, it 
is largely due to the expressive power induced by block structure and lexical 
scope. However block structure and lexical scope are not essential: in the mid 
80’s, Hughes, Johnsson, and Peyton Jones showed how to any block- 

structured program into recursive equations, which can then be efficiently com- 
piled on the G-machine [5,6,9]. Since then, lambda-lifting has had its ups and 
downs: it is used for example in at least one compiler and two partial eval- 
uators for the Scheme programming language [1,2,3]; in an unpublished note, 
“Down with Lambda-Lifting” [7], Meijer severely criticizes it; and it is no longer 
systematically used to compile Haskell programs today [8]. In all cases, lambda- 
lifting is considered as an intermediate transformation in a compiler or a partial 
evaluator. 

Our own stab at lambda-lifting is linguistic. We are interested in program- 
ming and in the expressive power induced by block structure and lexical scope, 
which lambda-lifting eliminates. This led us to devise an inverse transforma- 
tion to , . . . , recursive equations into a block-structured, lexically scoped 

program. Lambda-dropping was reported at PEPM’97 jointly with Schultz and 
implemented as the back-end of a partial evaluator [4,10]. In that joint work, 
we tried to emphasize the symmetric aspects of lambda-lifting and lambda- 
dropping: 
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lambda 

lifting 



scope-insensitive 
recursive equations 



block 

floating 



block 

sinking 



scope-insensitive 
block-structured program 



parameter 

lifting 



parameter 
dropping .■ 



scope-sensitive 
block-structured program 



lambda 

dropping 



Let us start from a block-structured program. A priori, this program contains 
free variables and is thus scope-sensitive. To make it scope-insensitive, we pass 
extra parameters to each of its locally defined functions. These extra parame- 
ters account for the free variables of each function. Once the program is scope- 
insensitive, we globalize each block by making it float to the top level and defining 
each of its locally defined functions as a global recursive equation.^ Conversely, 
lambda-dropping requires us to group recursive equations into blocks and make 
these blocks sink in the corresponding recursive equation, following the edges 
of the source call graph. The resulting program is block-structured but scope 
insensitive, except for the names of the (ex-)recursive equations, of course. We 
make it scope sensitive by preventing each function from passing variables whose 
end use is lexically visible. 

. , , Figure 1 displays the power function in ML. Many other 

examples exist [2,4,5,6,9,10] but this one is simple and illustrative enough. One 
of its parameters is “inert,” i.e., it does not change through the recursive calls. 
The lambda-lifted version carries the inert argument through each recursive call. 
The lambda-dropped version does not, making it instead a free variable in the 
actual traversal of the other argument. Lambda- lifting and lambda-dropping 
transform one definition into the other and vice-versa. 



. - , , - y - - - , - y Both naturally split into 

an .... and a . .,. _ . . Leaving aside block-sinking, which is specific 

to lambda-dropping, the analysis determines which parameters can be lifted and 
which parameters can be dropped. 

It is however a fact that most of the work in lambda-lifting and lambda- 
dropping has concentrated on its analysis and neglected its transformation. Both 
at PEPM’97 and at a meeting of the IFIP Working Group on Functional Pro- 
gramming in June 1997, we ventured that the correctness of lambda-lifting was 
still an open problem and there was a general agreement that it was so. 

^ Incidentally, we favor Johnsson’s style of lambda-lifting [6], where recursive equations 
are named and names of recursive equations are free in their bodies. This makes 
it possible to see them as mutually recursive top-level functions in a functional 
programming language. 
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fun power_l (base, 


0) = 1 


1 power_l (base, 


expo) = base * (power_l (base, expo - 1)) 


(* power_l : int * 


int -> int *) 


fun power_d (base. 


expo) 


= let fun loop 


0 = 1 


1 loop 


expo = base * (loop (expo - 1)) 


in loop expo 




end (* loop 


int -> int *) 


(* power _d : int * 


int -> int *) 


Fig. 1. A- lifted and A-dropped versions of the power function 



y We address parameter lifting and dropping and their formal correct- 
ness. More precisely, we want to know whether a lambda-lifted program and the 
corresponding lambda-dropped program compute the same function. 

We consider the meanings of the lambda-lifted and the lambda- 
dropped programs in a least-fixed point semantics [11]. Using fixed-point induc- 
tion, we prove that the lambda-lifted version and the lambda-dropped version 
of power compute the same function. 

, - . We generalize this example and introduce . . - - of 

lambda-lifting and lambda-dropping, i.e., 

Extensional lambda-lifting: a type-indexed mapping from the functional as- 
sociated to a lambda-dropped function to the functional associated to the 
corresponding lambda-lifted function; and 
Extensional lambda-dropping: a type-indexed mapping from the functional as- 
sociated to a lambda-lifted function to the functional associated to the cor- 
responding lambda-dropped function. 

- / In Section 2, we present two extensional, type-indexed transforma- 
tions respectively lambda-lifting and lambda-dropping a functional, and we show 
that the input and the output functionals share the same fixed point. These ex- 
tensional transformations assume that one knows which parameter(s) to lift or to 
drop. In Section 3, we scale up extensional lambda-lifting and lambda-dropping 
to mutually recursive functions. Section 4 concludes. 

2 Extensional Lambda-Lifting and Lambda-Dropping 

Lambda-lifting and lambda-dropping are defined intensionally, i.e., they are tex- 
tual transformations. Could we define their extensional counterparts, that we 
could apply to the corresponding meanings instead of to their text? We answer 
positively to this question by exhibiting two mappings between the functional 
corresponding to the lambda-dropped version of a function and the functional 
corresponding to its lambda-lifted counterpart. 
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2.1 Extensional Lambda-Lifting 

Let us define an extensional lambda-lifter for unary functionals abstracted by 
a dropped parameter. The lambda-lifter lifts the abstracted parameter in first 
position in the resulting uncurried binary functional. 

Definition 1. . A B . X . . . . . 

lifti : {X ^ {A^ B) ^ A-^ B) ^ {X X B) ^ X X B 

lifti F f {x, a) = F X {Xa'.f {x, a')) a 

This extensional version makes it possible to lambda-lift a functional prior 
to taking its fixed point. 

Theorem 1 (lambda-lifting). . A B . X . . , . . . 

F€X^ {A ^B)^A^B . , .ccGX .ogT 

A^B {F x) a = xxA^B (lifti F) {x, a). 

, By fixed-point induction. Let us define Rx as an X-indexed family of 
admissible relations between A ^ B and X x A ^ B: 

Rx = {(d, f) I Va G A.d a = £ {x, a)} 

Each Rx is pointed (contains {J-a^b, FxxA^b)) and admissible (it is defined 
as an intersection of inverse images by (continuous) application functions of the 
admissible equality relation). Now Vx G X and V(d, £) G Rx, 

(F X d, lifti F£)g Rx 

since Vo G A, lifti F £ {x, a) = F x (Aa'.f {x, a')) a 

= F X (Xa' .d a') a 
= F X da 

Therefore, by fixed-point induction, the least fixed points of the two functions 
are also related, i.e.. 



(fixA^B F X, fixxxA^B (lifti F)) G Rx 

which, expanding the definition of Rx, is precisely what we wanted to prove. □ 

Similarly, we can define an extensional lambda-lifter that lifts the abstracted 
parameter in second position in the resulting uncurried binary functional. 

Definition 2. . A B . X . . . . . 

Iift2 : {X ^ {A-^ B) ^ A-^ B) ^ {Ax X ^ B) ^ Ax X ^ B 
lift2 F f {a, x) = F X {Xa'.f {a', x)) a 
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2.2 Extensional Lambda-Dropping 

We now turn to defining an extensional lambda-dropper for uncurried binary 
functionals. The lambda-dropper drops the first parameter of the functional, 
assuming it to be inert. 

Definition 3. F : {A x X ^ B) A x X ^ B . inert in X 
yf € Ax X ^ B Wx G X ^ WaG A 

F a').f {x, a')) {x, a) = F (A(x', a').f {x' , a'}) (x, a) 

Definition 4. . A B AT ... . 

dropi : {{X X A^ B) ^ X X A^ B) ^ X ^ {A^ B) ^ A^ B 
dropi F X f a = F {X{x, a').f a') {x, a) 

This extensional version makes it possible to lambda-drop a functional prior 
to taking its fixed point. 

Theorem 2 (lambda-dropping). . A B AT .... . 

. Fg{XxA^B)^XxA^B.. .. X . , . X G X ^ 

aG A 

xxA^B F {x, a) = (dropi F x) a. 

, By fixed-point induction. Let us define as an X-indexed family of 
admissible relations between X x A ^ B and A ^ B: 

Rx = {{£, d) I Va G A1 {x, a) = da} 

Each Rx is pointed and admissible. Now \/x G X and V(£, d) G Rx, 

{F £, dropi F X d) G Rx 

since Va G A, drop^ F x d a = F {\{x' , a').d a') {x, a) 

= F {X{x' , a!). I (x, a')) {x, a) 

= F {\{x' , a')I {x’ , a')) {x, a) since F is inert in X 
= F £ {x, a) 

Therefore, by fixed-point induction, the least fixed points of the two functions 
are also related, i.e., 

(fixxxA^B F, fixA^B (dropi F x)) G Rx 

which is what we wanted to prove. □ 

Similarly, we can define an extensional lambda-dropper that drops the second 
parameter of an uncurried binary functional, assuming it to be inert. 

Definition 5. . A B . X . . . . . 

dropi : {{Ax X ^ B) ^ Ax X ^ B) ^ X ^ {A^ B) ^ A^ B 
drop;^ F X f a = F {X{a' , x).f a') {a, x) 
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signature LIFT2 
= sig 

val liftl : (’e -> ((’a -> ’b) * (’c -> ’d) -> ’a -> ’b) * 

((’a -> ’b) * (’c -> ’d) -> ’c -> ’d)) -> 

((’e * ’a -> ’b) * (’e * ’c -> ’d) -> 

’e * ’a -> ’b) * 

((’e * ’a -> ’b) * (’e * ’c -> ’d) -> 

’e * ’c -> ’d) 

end 

structure Lift2 : LIFT2 
= struct 

fun liftl F 

= (fn (f,g) => fn (xl, x2) => let val (F1,F2) = F xl 

in FI (fn a2 => f (xl, a2) , 

fn a2 => g (xl, a2)) x2 

end, 

fn (f,g) => fn (xl, x2) => let val (F1,F2) = F xl 

in F2 (fn a2 => f (xl, a2) , 

fn a2 => g (xl, a2)) x2 

end) 

end 

Fig. 2. Extensional lambda-lifting for mutually recursive functions 



signature DR0P2 
= sig 

val dropl : ((’e * ’a -> ’b) * (’e * ’ c -> ’d) -> 

’e * ’a -> ’b) * 

((’e * ’a -> ’b) * (’e * ’c -> ’d) -> 

^e * ^ c -> ^d) -> 

’e -> ((’a -> ’b) * (’c -> ’d) -> ’a -> ’b) * 

((’a -> ’b) * (’c -> ’d) -> ’c -> ’d) 

end 

structure Drop2 : DR0P2 
= struct 

fun dropl (FI, F2) xl 

= (fn (f, g) => fn x2 => FI (fn (al, a2) => f a2, 

fn (al, a2) => g a2) (xl, x2) , 
fn (f, g) => fn x2 => F2 (fn (al, a2) => f a2, 

fn (al, a2) => g a2) (xl, x2)) 

end 

Fig. 3. Extensional lambda-dropping for mutually recursive functions 
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signature FIX2 
= sig 

val fix : ((’a -> ’b) * (’c -> ’d) -> ’a -> ’b) * 

((’a -> ’b) * (’c -> ’d) -> ’c -> ’d) -> 

(’a -> ’b) * (’c -> ’d) 

end 

structure Fix2 : FIX2 
= struct 

fun fix (fl, f2) 

= (fn al => fl (fix (fl, f2)) al. 

fn a2 => f2 (fix (fl, f2)) a2) 

end 

Fig. 4. Applicative-order fixed-point operator for pairs of functionals 



2.3 Inverseness Properties 

It is a simple matter to check that drop^ olifti = identity and that lifti odropj^ = 
identity over functionals that are inert in their first parameter. 

3 Scaling up to Mutual Recursion 

Extensional lambda-lifting and lambda-dropping scale up to mutual recursion, 
along the lines of Section 2. 

For the record, Figure 2 displays an extensional lambda-lifter for a pair of 
unary functionals abstracted by a dropped parameter, using ML as a meta- 
language. The lambda- lifter lifts the abstracted parameter in first position in 
the resulting pair of uncurried binary functionals. Similarly, Figure 3 displays 
an extensional lambda-dropper for a pair of uncurried binary functionals. The 
lambda-dropper drops the first parameter of the two functionals. The dropped 
parameter is assumed to be inert. 

These pairs of functionals require a fixed-point operator such as the one in 
Figure 4. 

For example, here is a lambda-dropped pair of functionals computing the 
parity of a non-negative integer. Their fixed point is the pair of mutually recursive 
functions even and odd, parameterized with the value to test for the base case. 

val mkFodd_even_d 

= fn b => (fn (ev, od) => fn n => (n = b) orelse od (n - 1) , 
fn (ev, od) => fn n => (n > b) andalso ev (n - 1)) 

(* 

mkFodd_even_d : int -> (’a * (int -> bool) -> int -> bool) * 

((int -> bool) * ’b -> int -> bool) 

*) 

The corresponding two lambda-dropped parity functions are obtained by 
instantiating the base value and taking the fixed point of the result: 
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val (even_d, odd_d) 

= Fix2.fix (mkFodd_even_d 0) 

(* 

even_d : int -> bool 
odd_d : int -> bool 

*) 

Applying Lift2.1iftl to the lambda-dropped pair of functionals yields the 
corresponding lambda- lifted pair of functionals: 

val Fodd_even_l 

= Lift2.1iftl mkFodd_even_d 

(* 

Fodd_even_l : ((int * int -> bool) * (int * int -> bool) -> 
int * int -> bool) * 

((int * int -> bool) * (int * int -> bool) -> 
int * int -> bool) 

*) 

And indeed, simplifying Lift2.1iftl Fodd_even_d yields: 

(fn (ev, od) => fn (b, n) => (n = b) orelse od (b, n - 1) , 
fn (ev, od) => fn (b, n) => (n > b) andalso ev (b, n - 1)) 

which is lambda-lifted. 

We obtain two mutually recursive lambda-lifted functions by taking the fixed 
point of this pair. Instantiating their first argument yields the parity functions: 

val (even_l, odd_l) 

= let val (even_aux, odd_aux) = Fix2.fix Fodd_even_l 
in (fn n => even_aux (0, n) , fn n => odd_aux (0, n) ) 
end 
(=t^ 

even_l : int -> bool 
odd_l : int -> bool 

*) 

Finally, applying Drop2.dropl to the lambda-lifted pair of functionals yields a 
lambda-dropped pair of functionals which is extensionally equivalent to the orig- 
inal lambda-dropped pair of functionals. 

val mkFodd_even_d’ 

= Drop2.dropl Fodd_even_l 

(* 

mkFodd_even_d’ : int -> ((int -> bool) * (int -> bool) -> 

int -> bool) * 

((int -> bool) * (int -> bool) -> 
int -> bool) 

*) 
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4 Conclusion 

Over the last ten years, only the analysis part of lambda-lifting and lambda- 
dropping have been investigated. Establishing the formal correctness of their 
transformation appeared to be still an open problem. We have introduced exten- 
sional versions of lambda- lifting and lambda-dropping to address this problem. 
For the sake of expository concision, we have concentrated on single recursive 
functions and only informally outlined how the approach scales up to mutually 
recursive functions. 

Concentrating on single recursive functions makes it clear how both lambda- 
lifting and lambda-dropping connect to the static-argument transformation in 
Haskell [4,8]. One thing we have not reported here (because it is a little tedious) 
is that lambda-lifting and lambda-dropping are correct both in a call-by-name 
language and in a call-by-value language. To this end, we defined the denota- 
tional semantics of two functional languages, one following call-by-name and one 
following call- by- value, and we considered the denotations of a lambda-dropped 
function and of a lambda-lifted function such as the power function of Figure 1: 
lifti and drop]^ respectively map one into the other and vice-versa. 

On the other hand, experimenting with mutually recursive functions reveals 
the practical limitations of extensional, type-directed lambda-lifting and lambda- 
dropping: handling block structure becomes daunting rather quickly. Some au- 
tomated support is needed here to study extensional lambda-lifting and lambda- 
dropping further. 
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Abstract. Snbtyping tends to undermine the effects of parametric poly- 
morphism as far as the static detection of type errors is concerned. Start- 
ing with this observation we present a new approach for type checking 
logic programs to overcome these difficulties. The two basic ideas are, 
first, to interpret a predicate type declaration as an approximation for 
the success set of the predicate. Second, declarations are extended with 
type constraints such that they can be more refined than in other con- 
ventional type systems. The type system has been implemented in a 
system called Typical which provides a type checker for Standard Prolog 
enriched with type annotations. 



1 Introduction 

There are quite a few approaches to typed logic programming. Several type sys- 
tems support parametric polymorphism and subtypes e.g. [28,12,8], see also the 
collection in [24]. In [18] a classification scheme for the various uses of types 
in logic programming is developed. It distinguishes three almost independent 
dimensions of using types in logic programming: , , , - > . 

. , . . , and , , , - - used in consistency 

annotations. Another aspect for the comparison of typed logic languages is how 
the semantics of typed predicates is defined, depending either on the clauses 
the type declarations (called , ^ [15]) or independent from type 

declarations (. . - . _ 

While there are many motivations for introducing types (naturalness of the 
representation, efficiency when using types as active constraints, etc.) the soft- 
ware engineering point of view seems to be the most important one: The aim 
is to detect as many programming errors as possible by static program analysis 
before running the program. In this paper, we argue that in logic programming 
subtyping tends to undermine the effects of parametric polymorphism as far as 
the (static) detection of type errors is concerned. To overcome these difficulties 
we use powerful type constraints in predicate type declarations which are inter- 
preted as approximations of the intended model. Here, we present an overview 
of the Typical system in which these ideas have been implemented. 
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In Sec. 2 we motivate our approach by showing shortcomings of polymorphic 
type systems with subtypes. In Sec. 3 we tailor the “types as approximations” 
dimension of [18] towards Prolog clauses. Sec. 4 describes the Typical system and 
shows how predicate declarations with constraints are used as approximations of 
the intended model. Typical has been applied successfully to various programs, 
including its own source code in Standard Prolog enriched with type annota- 
tions. In Sec. 5 we argue why the descriptive approach is useful for Prolog type 
checking. Finally, we give some conclusions and point out further work. 

2 Problems of Polymorphic Type Systems with Subtypes 

An ML-like type system for logic programming was proposed and used by 
Mycroft and O’Keefe [21]. It includes explicit type declarations and parametric 
polymorphism but no subtypes. Most prominently the languages Godel [11] and 
Mercury [29] are based on this kind of type system. But it is not possible to 
model often needed type hierarchies as in ‘integers are numbers and numbers 
are expressions’. 

There are many different proposals for combining a logical programming 
language with a type system comprising parametric polymorphisms as well as 
subtyping. Smolka uses type rewriting [28], partial order on type symbols is 
used by [3,12], Hanus proposes more general equational type specifications [10] 
and also Horn clauses for the subtype relation [9]. Naish uses Prolog clauses 
to define polymorphic predicates [22]; the predicate type is specified by some 
general constraint expression in [13], and so on. However, these approaches have 
a serious shortcoming when it comes to detect obviously ill-typed expressions 
involving subtypes. 

type male — > peter; paul . 
type female — > anne; mary. 
type person, 
subtype male < person, 
subtype female < person, 
pred f ather (male, person) . 

f ather (peter , paul) . 
pred mother (female, person) . 
mother(anne, peter) . 
mother (mary , paul) . 

The program defines a small type hierarchy with type person having (disjoint) 
subtypes female and male. By and large we follow the syntactical style used 
in [21]. Function symbols and their argument types are given by enumeration. 
Predicate declarations define the expected types of arguments. If we add 
pred ql (person). 

ql(X) father(X,Y), mother(X,Z). 
the clause for ql can be detected as ill-typed. The type constraints for the vari- 
able X, i.e., X:male and X:female are not simultaneously satisfiable. However, 



7o person 

7 . / \ 

7o female male 

7. 

7. 
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using the common parametric type declaration for equality, i.e., ’ = ’ : T x T, 
the clause for q2 in 

pred q2 (person). 

q2(X) father(X,Y), X = Xm, mother (Xm, Z) . 
is usually not detected as ill-typed (see e.g. [28,12]) although it is logically equiv- 
alent to ql! If the type parameter T in the declaration ’ = ’ : T x T is substituted 
by person, then X = Xm is not ill-typed, because the variable X has type male 
which is a subtype of person, and the same applies to the type female of the 
variable Xm. 

Note that the problem illustrated here does not depend on the equality pred- 
icate; as we will show in the next sections similar problems occur with many 
often-used polymorphic predicates like append, member etc. 

Subtyping tends to undermine the effects of parametric polymorphism in the 
conventional approaches as far as the detection of type errors is concerned. This 
anomaly seems to be generally neglected in the literature; [30] is an exception 
mentioning the weakness in type-checking, which is caused by the generally used 
method for combining subtypes and parametric polymorphism. We will present 
a new type system which enables static type checking and type inferencing to 
spot such errors. 

Logic programming in general has no modes for input/output. One way to 
attack the difficulties for type systems is to restrict logic programming towards a 
functional or directional style with fixed modes and then apply ideas known from 
typed functional programing (c.f. Sec. 6). Our approach instead is to extend the 
type system and make it suitable for general logic programming. 

3 Types as Approximations 

In this section, by tailoring the “types as approximations” dimension of [18] 
towards Prolog clauses, we develop a general method of static program analysis 
for finding programming errors like the ones illustrated in the examples above. 
We interpret predicate declarations as consistency annotations and take these 
annotations as approximations of a set of atoms intended to be true. We will 
discuss the applicability of consistency annotations and show how they can rea- 
sonably be used to find erroneous expressions. Specific instances of the general 
scheme we present here can be found as part of many proposed type systems 
(e.g. [22]), although mostly it is used only indirectly. 

3.1 Consistency Annotations 

For the beginning we will allow a rather general form of predicate declarations. 
For each predicate p we assume that there is a function . p which generates an 
appropriate constraint over some theory. The function . p is directly or indirectly 
defined by the type declaration for the predicate p. Given a syntactically well- 
formed atom A = p(. . .), then . p(A) yields a constraint which is wanted to be 
satisfiable, otherwise A is called ill-typed. 
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Intuitively, the declaration is an approximation of the set of atoms p {. . .) 
which should be true. I.e., a model intended by the programmer is described in 
two ways: first by the logical clauses and second by the predicate type declara- 
tions. Of course, in practice the predicate declarations are much simpler than 
the clauses and they only roughly approximate the intended meaning of a predi- 
cate. Thus, for any program we can distinguish the following three models whose 
possible interrelationships are illustrated as in the following diagram: 




p) The program clauses alone define some model shown as region p; this model 
is of central importance. Based on the formal semantics of the program- 
ming language in general this model exactly represents the meaning of the 
program, i.e., which facts are true and which are false, 
a) The predicate types also define a model that may be different from the 
program model. With ‘types as approximations’ the model of the predicate 
declarations, or annotations in general, should be a superset of the model of 
the program clauses. 

i) Last but not least, the intended model, i.e., what the program should com- 
pute as required by the application domain, is just another model. In an ideal 
program the program model should be the same as the intended model. 

We do not use the annotation model a in a specification of a program. This differs 
from the equation ’’Specification = Program -|- Types” in [22]. A consequence 
of the approach in [22] would be to further include modes and other implicit or 
explicit assumptions in the specification for a program. 

Let us now discuss various cases where the model of the program clauses p 
coincides or differs from the other models: 

p = i) In the optimal case the program model coincides with the intended 
model. I.e., the set of inferred solutions is exactly the set wanted by the 
programmer. Formal annotations describe some superset of the intended 
and inferred model. 

a \ p 7 ^ 0) There is no problem if the model of annotations a is a strict superset 
of the program model p. Annotations are not required and are not even 
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intended to describe the model as exactly as the program clauses. They can 
only provide an approximation as far as it can be described using the type 
language alone. 

p \ a yf 0) A program may happen to have solutions which are not consistent 
with the type annotations, i.e., these solutions are ill-typed and they are 
marked as being errors. Such an error may also be due to an inappropriate 
type declaration. If an inconsistency between a program solution and the 
annotations is detected, it is not possible to decide automatically whether 
the program clauses or the annotations are not correct; this decision depends 
on the intended model. 

i \ p yf 0) If a solution in the intended model is not computed by the program 
then this corresponds to an error because an intended answer is missing, 
p \ i yf 0) The difference of the program model and the model intended by the 
programmer marks inferred solutions which are ‘not wanted’ by the program- 
mer. E.g., ‘appendC [] ,3,3)’ is true w.r.t. the usual untyped implementation 
of append. 

Of course, if we do not have a formal description of the intended model i, we do 
not have a chance to automatically analyze the cases involving i. Since in this 
paper we do not want to deal with formal program specifications other than the 
discussed annotations we will therefore use the annotations as a specification 
of a superset of the intended model and assume i C a. As a consequence, the 
declarations can be used for static type checking purposes in the following way: 
each program clause is inspected statically if it contains expressions, possibly 
the whole clause, that do not fit with the semantics given by the predicate 
declarations. If the checking procedure finds that some expression is inconsistent 
with the declaration then probably a programming error is detected. In all cases 
the semantics of the clauses remain unaffected and well-defined. This is similar 
to the detection of redundant code, e.g., unreachable statements in a procedural 
program, which is done by many state-of-the-art compilers. 

3.2 Inconsistent Atoms 

For any atom A = p(ti, ■ ■ ■ ,tn) the type-constraint is given by . p{A). For sim- 
plicity we often write . (A). If there is no type declaration for p in the type part, 
by default we take the type constraint to be . , . 

Clauses that conflict with the predicate declaration will be called , 

- . . or. ... . . We argue that such clauses are useless in the program 

because they contain subexpressions which are not satisfiable in the intended 
model. A sound but not necessarily complete algorithm for detecting ill-typed 
clauses will point out clauses which conflict with the type declaration of the 
head atom, or which can be eliminated without affecting the semantics of the 
specification. These two cases can be illustrated by the following specification: 
:- pred p(male) . 7„ type declaration 

p(peter) :- p(l) . 7, body is always false 

p(2) . 7o conflict with the type declaration 
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In the intended semantics implied by the type declarations, the body of the first 
clause is not true. If the body of a clause is known to be unsatisfiable due to its 
inconsistency with the type declarations, then such a clause can be called useless: 
it is logically redundant. Also the second clause is inconsistent. Usually there is 
no reason for a programmer to write such a clause having an unsatisfiable type 
constraint, in this case 2:male. 

For every atom A that has an instance which is true in the intended model, 
we assume that . (A) is satisfiable. This is a very important assumption, because 
it gives the programmer a device to describe properties of the intended model. 
If for some atom A we can show that the type constraint . (A) is not satisfiable, 
then we have found an atom that has no instance in the intended model. This 
simple correspondence is the basis for an automated type checking method where 
unsatisfiable type constraints indicate programming errors. 



3.3 Consistency Checks for Clauses 

In a program we could translate each clause into a formula where every atom 
A is replaced by the type constraint . (A). If the transformed formula is not 
satisfiable, we have shown, using our basic assumption, that the original clause 
is not satisfiable in the intended model of the program. Hence, the original 
clause probably contains an error (at least, it is inconsistent with the annotation 
model). As we will show in the following, in practice we can make a more detailed 
analysis of program clauses exploiting predicate declarations. 



Horn Clauses: First consider a program which is given by Horn clauses. If there 
is a simple fact p(. . .) and . p(p(. . .)) is not satisfiable, then the fact contradicts 
with the intended model as specified by the predicate declaration. Hence this 
fact can be marked as erroneous, it contains a programming error with respect 
to the predicate declaration. A similar line of reasoning applies to clauses 
A <— i?i, . . . , Bn- 

where A and Bi are atoms. If the conjunction of type constraints . (Hi) A ... A 
. (Bn) is not satisfiable, we know that the body of the rule is not satisfiable 
(in the intended model). Formally, the complete clause together with the type 
constraints is a tautology, but practically we can say that the clause is useless. 
I.e., if such a clause appears in a logic program, this clause can be marked 
as containing a type error. A similar view is generally taken in type inferencing 
frameworks for Prolog, starting with [19]. Furthermore, it is reasonable to require 
the type constraint 

. (A) A. (Hi) A... A. (Bn) 

to be satisfiable. Otherwise the body of the rule would imply an atom A that 
contradicts the consistency requirement as given by its declaration. 



Clauses with Negation: In the general scheme we develop here we want to be 
independent of specific semantics for negation. We assume that for an atom C 
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such that a model does not contain any instance of it, with any reasonable 
semantics of negation not C is true in the model. If in the extended Horn clause 

A <— i?i, . . . , not C 

. (C) is not satisfiable then not C will thus be true in the intended model, 
and therefore this subexpression can be seen as practically useless. Also, if 
. (Hi) A ... A . {Bn) A . (C) is not satisfiable, then we either know that the 
conjunction Hi, ... , H„ always fails or not C is always true when the conjunc- 
tion Hi, . . . , H„ succeeds. In both cases we can argue that the body of the rule 
contains a programming error. As before, we will also require the type constraint 
of the head atom to be satisfiable simultaneously. I.e., if the type constraint 
expression 

. (A) A. (Hi) A... A. (H„)A. (C) 

is not satisfiable, we argue that the clause contains a type error. If there is more 
than one negated atom in an extended Horn clause, i.e. we have 

A ^ Hi, . . . , H„,not Cl,..., not Ck 

we require 

. (A) A. (Hi) A... A. (H„)A. (Ci) 

to be satisfiable for each atom Ci. We will take a closer look at the following 
rule, referring to Example 1: 

pred p (person) . 

p(P) not mother (P,X) , not father(P,Y). 

Intuitively, p is true for persons that are neither mother nor father of someone. 
If we required the variable P to be of type female, due to its occurrence in 
mother (P ,X) , and also to be of type male, due to its occurrence in f ather (P, Y) , 
then these constraints would not be simultaneously satisfiable, because the types 
female and male are disjoint. Instead, with our condition the rule for p has no 
type error. It is interesting to note that there are other proposals such as [12], 
which view this clause as not being well-typed. The reason is that the variable 
P is required to have a unique type such that all atoms are well- typed, including 
both negated atoms. We think that this requirement is appropriate for pure Horn 
clauses but that in general it is too strong for predicate logic formulas or their 
variants with negation as failure as the given example illustrates. 



4 The Typical System 

The aim of Typical is to do static type checking on logic programs. The software 
will check Standard Prolog programs that are extended with type declarations. 
The type system includes subtyping and parametric polymorphism. In addition 
to the usual Prolog clauses. Typical expects type definitions and predicate decla- 
rations. No type declarations for variables are needed; variable types are inferred 
automatically by Typical. 
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4.1 The Type Language 

Here we give an overview on the language for defining types in Typical. The basic 
form of monomorphic type definitions are the same as already used in Example 1. 
If a function symbol has arguments, then the corresponding types must be given 
in the definition 

type machine — > fastmCint , string) ; slowmCint , string) . 
Parametric types are defined by using type variables and they can be ordered in 
the same way as other types. However, the parameters of parametric types that 
have a subtype relation must be the same. E.g., a complete type definition for 
the ubiquitous list and for binary trees modelled as a subtype of trees in general 
could look like 

type list(T) — > [] ; [ T I list(T) ] . 

type bintree(T) — > leaf(T) ; bnode(T,bintree(T) ,bintree(T)) . 
type tree(T) — > node(T, list (tree(T) ) ) . 
subtype bintree(T) < tree(T). 

Note that infix notation for operators and types mix well. 

There are various technical conditions the defined type hierarchy must ful- 
fill, e.g. the existence of greatest lower bounds for non-disjoint types required 
for the existence of principal types as needed in Sec. 4.3. For technical simplic- 
ity we assume that each function symbol has a unique declared type. Subtype 
relationships must be given explicitly, we do not automatically detect subtyping 
between types if the set of terms in one type is a subset of the terms in another 
type. A precise description of these conditions is given in [17]. 



4.2 Predicate Declarations 

Predicate declarations specify the types which are expected for the actual argu- 
ments when a predicated is called. E.g., if the first argument of a predicate 
sumlist must be a list of integers and the second argument must be an integer, 
the declaration is 

pred sumlist (list (int) , int)). 

Declarations may also contain (implicitly existentially quantified) type parame- 
ters, written as Prolog variables, e.g., for append 

pred append(list (T) , list(T), list(T)). 

More specific type declarations are possible by using . . . . . . over type 

variables occurring in the declaration. In order to identify this new form of 
declarations syntactically, we prefix type parameters within formal argument 
types with ’O’ [16]: 

pred sublist (list (0T1) , list(@T2)) |> T1 =< T2 . 

The expressions on the right of I > describe type constraints where =< stands for 
the subtype relationship. Syntactically similar type declarations have been used 
independently for type dependencies in [7] and in [23]. 
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4.3 Approximations and Type Consistency 

We first illustrate the use of the new form of type declarations for predicates 
by means of an example. Intuitively, in Typical a type declaration for a pred- 
icate describes a superset of the predicate solutions (cf. Section 3). E.g., the 
conventional declaration 

pred appendg^^jClist (T) , list(T), list(T)). 
defines that for any (ground) atom append (LI, L2,L3), which is true in some 
model, there is a type substitution O for the type parameter T such that each 
argument is of type 0(list(T)). With type hierarchies, possibly being rather 
deep or even containing a most general type, this semantics leads to anomalies 
as pointed out in Section 2. As part of our solution we allow for more exact 
declarations using type constraints: 

pred appendjj^g^jClist (OTl) , list(@T2), list(@T3)) 

|> T1 =< T3, T2 =< T3. 

Now an atom append (L1,L2,L3), where the arguments LI, L2, and L3 have 
the, - (or , list (A), list(B), and list(C) respectively, is 

well-typed (also called type consistent) if the conjunction of type constraints 
A =< C , B =< C is satisfied. 

We can easily transform the declaration for appendgy^j into an equivalent 
one using the new framework, yielding 

pred appendg^^jClist (OTl) , list(@T2), list(@T3)) 

|> T1 =< T, T2 =< T, T3 =< T. 

which is obviously weaker than the appendjjgy declaration. (Note that type 
variables occurring only in the constraint part of a predicate declaration - like T 
here - are implicitly existentially quantified.) The following figure illustrates the 
type constraints imposed by appendgy^j and appendjjgy, respectively: 



T Ts 




Ti T2 Ts Ti T2 



Now consider the appendjjgy declaration. Since predicate declarations are 
seen as annotations that approximate the intended semantics of the program, the 
atom appendC [1] , [-1] ,L) is well-typed with the variable L having the (least) 
type list(int). Given the least type of the first argument [1] as list(nat) 
and the least type of [-1] as list (negint) , the type constraints nat =< int 
and negint =< int are satisfied. 

On the other hand, if the variable L is constrained to the type list (nat) 
the same atom is not well-typed, because there is no type T2’ such that [-1] 
has (least) type list(T2’) and also T2’ =< nat. This indicates that the atom 
as a goal literal will always fail, because with the intended meaning there is no 
list of natural numbers that contains a negative number. 
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Similarly, the atom append(L2, [-1] , [1] ) is not well-typed under the decla- 
ration for appendjjg^j although it is considered well-typed w.r.t. the conventional 
typing for appendgi^- 



4.4 Principal Types 

One of the central notions within the Typical type system is the , 
of a term, which is the most specific type of a term. A principal type tt of the 
term t has the property: t has type tt (denoted as f : tt) and if t has type r then 
there is a type substitution 0 such that 0{tt) < r, i.e., 

7T is principal type of t <t4> t : n and (Vr) (t : r (36>) 0{tt) < r). 

The principal type is as minimal as possible with respect to the type order, but 
it is also as polymorphic as possible. 

Given the type declaration 
type pair(T, S) — > mkpair(T, S) . 

and usual declarations for int and list then the term mkpair([l] , [] ) has 
type pairdist(int) ,list(int)), as well as pairdist(nat) ,list(nat)), 
pair (list (nat) ,list(T)), etc. The latter is the principal type of the term. 

The notion of principal types is well-known from typed functional programming. 
Our definition is somewhat different because in our framework we don’t have A- 
abstraction and the principal type does not depend on type constraints.^ 

The syntactical appearance of type constraints in declarations is similar to 
declarations in functional programming with parametric types and subsumption 
[20,6], commonly known as F<. However, their impact within Typical is rather 
different. As an important factor we will see that a type parameter with an 
O-prefix matches with the principal type of an argument term. Therefore, a 
declaration for appendj^g^j should ... be seen as a simple ‘logical variant’ of 
functional declarations such as 

func app : list(Tl) xlist(T2) xlist(T3) — > bool with T1<T3, T2<T3. 
func app: list(Tl) xlist(T2) — > list(T3) with T1<T3, T2<T3. 
because of the following observations: The first function declaration is simi- 
lar to appendgp(j because the expression app([l] , [-1] ,L) is well-typed even 
if L has type list (nat). The type parameter T3 can be instantiated with 
int. The second function declaration is closer to the declaration appendj^gy 
in Typical. An equation L = app( [1] , [-1] ) is detected as ill-typed when L has 
type list (nat). However, this requires a fixed partitioning of input and output 
arguments which is not appropriate in logic programming. 

^ A similar definition of principal types is used in [12]. Neglecting technical problems 
in [12] (see [2]) our approach is rather different in the way how principal types are 
used for checks of type consistency. 
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4.5 Procedure for Type Consistency Checks 

In general, a predicate declaration has the form 
p : patterii]^ . . . pattern^ [> Constraint. 

Given some atom p {. . .), for each argument we will determine the most specific 
instance of each pattern^ that matches the type of the corresponding argument 
and the constraint part is checked for satisfiability. Thus, in order to check if an 
atomp(ti, . . . , tn) is type-consistent with respect to a declaration^ : tti . . . 7 t„>C 
the following steps are performed (where the whole procedure fails if any of the 
steps fails): 

1 . compute the principal type of every argument ti, 

2 . for each determine the least instance 0i{TTi) with Ti < 0 i( 7 Ti), 

3. check if there is a substitution 0 such that 0{-Ki) = 0 i( 7 Ti) for each i. 

4. check if 0(C) is satisfiable. 

The first three steps implement the abstract function . p as used in Section 3.1. 
As usual, a clause is type-consistent if every atom in it is type-consistent w.r.t. 
the same variable typing. 

The steps to compute type consistency are illustrated by checking 
the atom append! [] , [- 1 ] , [ 1 ] ) with respect to the declaration 
pred appendj^g^jClist (OTl) , list(@T2), list(@T3)) 

|> TI =< T3, T2 =< T3. 

In the first step the principal types for the argument terms are computed. The 
empty list [] has the principal type ti = list(a). For [-1] and [1] the principal 
types are T 2 = list(negint) and T 3 = list(nat), respectively. If there was any 
argument term which is not type correct, e.g., [ 1 | 2 ] does not conform to the 
declaration of [_l_] because 2 is not a list, then the atom would not be type 
consistent. 

Second, the principal types Ti are matched against the formal types in the 
predicate declaration. The least instances 0i{'Ki) are given by 0i = {TI ^ a}, 
02 = |T2 ^ negint}, and 03 = |T3 ^ nat}. If there is no least instance of a 
formal type tt^, e.g., if an integer occurs where a list is expected, then the atom 
would not be type consistent. 

Third, all substitutions are combined into a single substitution 0 = |T1 <— 
a, T2 ^ negint, T3 <— nat}. In case of conflicts between the single substitutions 
0i, e.g., if 03 was |T2 ^ nat} then the atom would not be type consistent. 

In the last step we determine that the constraint set 0({T1 < T3, T2 < T3}) = 
{a < nat, negint < nat} is not satisfiable. Hence, append! [] , [- 1 ] , [ 1 ] ) is not 
type consistent. For the atom append! [] , [1] ,[!]), however, we would get the 
set of constraints {a < nat, nat < nat} which is satisfiable with the substitution 
{a ^ posint}, i.e., the modified atom is type consistent. 

Consider the Typical type declaration 
pred : @T x @T. 
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With this declaration for ’=’ the type error in the clause (from Section 2) 
q2(X) father(X,Y), X = Xm, mother (Xm, Z) . 
is detected since the atom X = Xm with X of type male and Xm of type female is 
illtyped. 



Using the declarations 
pred absCint, nat) . 

pred member (OTl, list(@T2)) |> T1 =< T2 . 
the expression 

member (X, [-1,-2] ) , abs(Z,X) 

is found to be not type consistent: The principal type of X in the first subgoal is 
inferred to be negint which is incompatible with the type nat required for X in 
the second subgoal. 

Further examples of type declarations in Typical are: 

:- pred reverse (list (@T) , list(@T)). 

7o principal types of arguments must be identical 

:- pred intersection(list(@Tl) ,list(0T2) ,list(@T)) |> T=<T1, T=<T2 . 
7„ intersection(Ll,L2,L) :- elements of L are in both LI and L2 . 

:- pred overlap (list (@T) , list(@U)) |> V =< T, V =<U. 

7o overlap (LI ,L2) :- lists LI and L2 have members in common. 

Our notion of ill- typing does not preclude standard Prolog idioms, such as 
the failure driven loop. For instance, consider 

q :- p(X), side_ef f ect (X) , fail, 
q :- succeed. 

where we assume that p and side_effect constrain their arguments to be of 
the same type and the type constraints of the nullary predicates are always 
true. Although in a purely declarative setting the body of the first clause is not 
satisfiable (assuming fail to be always false), i.e. the whole clause is trivially 
true, it is not rejected as ill-typed because we use the constant . , as type 
constraint for the atom fail. 

In [17] typing rules are given that precisely define well-typedness for a pro- 
gram and clauses by a set of logical inference rules. A complete type inferencing 
algorithm together with a description of the involved (finite domain) constraint 
solving over a partially ordered set of type symbols is also given in [17]. 

5 Why Syntactical Type Checking is Useful for Prolog 

By writing type declarations for predicates, the programmer gives hints on the 
intended semantics for that predicate. Every atom intended to be true shall be 
well-typed with respect to the declaration. Nevertheless, our type system pre- 
sented so far remains purely syntactical. While a corresponding semantics for 
well-typed models could be defined, e.g. using results from [9], we believe that 



Using Types as Approximations for Type Checking Prolog Programs 263 



it is reasonable to consider syntactical type checking for its own. Assume a pro- 
grammer wants to define the absolute difference of numbers by the (erroneous) 
clauses 

pred absdistCint, int , nat) . 

absdist(X,Y,D) : - X < Y, D is Y - X . 
absdist(X,Y,D) X >= Y, D is Y - X. 

Of course, the second clause should have ‘D is X-Y’ instead of ‘D is Y-X’. Both 
clauses are well-typed under the variable typing {X:int, Y:int, D:nat}. Neverthe- 
less, using normal Prolog-resolution, the goal absdist(5,4,D) gives the result 
D = -1, which is not intended and, even more, does not correspond to the type 
declaration of the predicate absdist. With respect to the type system the usual 
reaction is to reject such an approach for typed logic programming and require 
the resolution and its unification to obey the type constraints on variables. In 
that case, i.e. using an inference calculus implementing the correct order-sorted 
unification as in e.g. [3], the goal absdist (5, 4, D) fails. With respect to detect- 
ing the programming error in this example, the practical consequences of using 
or leaving out order-sorted unification are essentially the same: the program is 
well-typed but it does not produce the intended results. Type-correct inference 
calculi tend to (correctly) produce a logical failure instead of reporting a type- 
error. Here a difference between our approach and [22] becomes apparent. While 
[22] uses checks for type consistency to find clauses which would produce a type 
incorrect answer, we use type consistency also to find clauses which produce no 
answer at all. 

Thus, rephrasing Millner’s slogan 

4 y yields . . . . y- , y . , - — . . , y - y / . y . On the other 

hand, for our types-as-approximations approach whose purpose is to detect use- 
less atoms and clauses we get the slogan . . . . 

Is it reasonable to allow the logic inference calculus to produce results that do 
not conform to type declarations? On the positive side there are strong practical 
arguments: We have a type system that allows natural modeling of data struc- 
tures and also enables detailed static program analysis proceeding incrementally 
clause by clause. At the same time the runtime execution of the program can 
still be done by any (efficient, commercially available) Prolog system that does 
not have to provide any form of typed unification. Other approaches to define 
an expressive type system and a new typed inference calculus in combination 
sometimes have to cope with severe undecidability problems, or they restrict the 
language or impose a run-time overhead that is not accepted by most program- 
mers. 

6 Conclusions and Further Work 

Generally used type systems for logic programming with parametric polymor- 
phism and subtyping have an anomaly which weakens the ability to detect type 
errors as shown in Sec. 2. Our new type system Typical overcomes this anomaly. 
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It provides type checking at a very detailed level without restricting common 
programming practice. 

The Typical typing approach is independent of any mode system for 
specifying an input/output behavior for predicates. In this way it dif- 
fers from other proposals e.g., using so-called implication types [26,25] 
or type dependencies (e.g. [14]). An example for a type dependency is 
append{list(T),list(T),list(T)/l,2 3; 3 ^ 1,2). Its meaning is: For all 
T, if the first two arguments of append have the type lister) then so does the 
third argument, and vice-versa. This type dependency has a similar effect for 
append as our declaration with type constraints. But there are other declara- 
tions, e.g. for overlap, that are not expressible with type dependencies. Typical 
does not impose a functional or directional view on logic programs as it is done by 
further systems with ‘directional types’ and variants thereof (see e.g. [5,27,1,4]). 
It doesn’t matter if the inference calculus is top-down as in Prolog or bottom-up 
as it can be in a deductive database system. In [7] and similarly in [23] mode 
declarations are used which are syntactically similar to our type declarations. 
However, in Typical the declarations are exploited for checking clauses for logical 
consistency with the model of the declarations instead of checking input/output 
correctness. 

Here, we could only present an overview of the complete type checking and 
inferencing algorithms underlying Typical; they are spelled out in detail in [17]. 
Apart from providing a method for dealing with negation. Typical contains sev- 
eral extensions for higher-order programming and extra-logical built-ins (e.g. a 
built-in type goal which is used in declarations like : - pred call (goal) . ) such 
that the system could be applied successfully to its own source code of about 
4000 lines of Prolog code [16,17]. A more refined treatment of such higher order 
features within the types-as-approximations approach is subject of our current 
work. 
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Abstract. We enrich the domain Vos by combining it with types. This 
makes static analysis more precise, since deduced properties concern both 
terms considered as a whole, and the details of their structure, as it is 
defined by types. We use this enriched domain to redefine first-order 
groundness analysis (PROLOG terms) as it is formalized by Codish and 
Demoen [CD95] and higher-order groundness analysis (AProlog terms) 
as defined by the authors [MRB98]. 



1 Introduction 

The works presented in this article as been stimulated by the study of static 
analysis for AProlog [Mal99], but applies equally well to typed versions of 
Prolog. 

Our purpose is not to define a new type analysis for Prolog or for AProloG; 
there are already several proposals, and in facts, PROLOG and AProlog do not 
diverge too much as far as , _ typing is considered 

[M084,Haii89,LR91,NP92,LR96]. The prescriptive point of view considers well- 
typing as a property of programs, and relates it to the semantics of program , . 

a . , . _ . . theorem which says roughly that “Well-typed programs 

cannot go wrong” [Mil78]. In the prescriptive view, one can consider as ill-typed 
programs and goals with a perfectly well-defined (but undesired) semantics. For 
instance, one can reject every program where a call to the classical predicate 
append has arguments that are not lists (though append([], 3, 3) is a logical con- 
sequence of the standard semantics). In a sense, the prescriptive view bridges 
the gap between the intended semantics of a program and its actual semantics. 

Our purpose is to combine existing informations about types with informa- 
tions that can be expressed in a domain like Vos [CFW91,MS93]. So doing, we 
expect a better precision as illustrated in the following example. In a non-typed 
groundness analysis using Vos, if an element of a list is non-ground, all the list is 
said to be non-ground (e.g., [A, 2,3]). An incomplete list is deemed non-ground 

* This work was done while the author was at Ecole des Mines de Nantes. 
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as well (e.g., [1,2,3|Z]), so that groundness analysis with domain Vos does not 
make a difference between these two cases. However, predicates such as append 
see the difference because they have only to do with the structure of lists. If 
the length of an input list is unknown, they try to complete it by unification 
and backtracking, but if it is known, these predicates are deterministic. So, it 
is important to formalize the difference between a proper^ list of ground ele- 
ments (which we will write^ {Usta true) or, equivalently, true), a proper list 
of not-all-ground elements (written (lista false)) and an improper list (written 
false). 

Predicates like append are especially interested in the structure of lists be- 
cause they are generic; i.e., they are defined for lists in general, without con- 
sidering the types of elements. This is what the type declarations of these 
predicates indicate formally; they are polymorphic, e.g., type append [list A) 
— > {list A) — > {list A) o. This suggests to model the expression of abstract 
properties on the expression of polymorphism. So, we will derive from the pres- 
ence of type variables in declarations (e.g., A in {list H)) abstract domains which 
are more refined than the ordinary Vos domain (i.e., a two-value domain: true 
and false). Thus, in the case of lists, the abstract domain contains values true, 
{lista false), {lista {Usta false)), etc. 

In the sequel, we first analyze the case of a typed variant of PROLOG in Sec- 
tion 2, and then the case of AProlog in Section 3. Section 2 also briefly presents 
the domain Vos and the abstract compilation of groundness for Prolog, while 
Section 3 contains an introduction to AProlog and to the abstract compila- 
tion of groundness for AProlog. We discuss correctness and termination of our 
proposal in Section 4. 



2 Typed Properties for Prolog 

We combine Vos with simple types in the static analysis of PROLOG programs. 
We first recall the principles of abstract compilation, and then we expose our 
technique. 



2.1 Abstract Compilation 

The principle of abstract compilation is to translate a source program into an 
abstract program whose denotation is computed according to its concrete se- 
mantics. This can be seen as a way of implementing abstract interpretation by 
partially evaluating it for a given program. This technique is called abstract com- 
pilation by Hermenegildo . [HWD92] and originated from works by Debray 

^ Proper/partial/incomplete are used here as in [O’K90]. I.e., A “proper” Thing is a 
non-variable Thing each of whose Thing arguments is a proper Thing; A “partial” 
Thing is either a variable or a Thing at least one of whose Thing arguments is a 
partial Thing; Partial Things are sometimes ealled “incomplete” Things. 

^ Everywhere in this article, when a program symbol is reused to express an abstrac- 
tion, we write its abstract version with a subscripted a. 
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and Warren [DW86]. Codish and Demoen apply it to the analysis of groundness 
for Prolog programs [CD95]. 

The analysis proceeds in several phases, but we only focus on the translation 
of a program P into a program Pa whose denotation approximates the non- 
ground minimal model of P (e.g., as defined in the S-semantics [FLMP89]). 

All programs must be normalized before being translated. Normalization is 
independent from the analyzed property. The purpose of normalization is to 
make every unification step explicit, and to make sure that every goal corre- 
sponds to a single unification step. So, there must be at most one constant in 
every goal, and all variables of a goal must be different. More precisely, PROLOG 
programs are normalized in a way such that every atom occurring in a program 
clause is either of the form X = Y, p{Xi , . . . , Xk), or Xq = f{Xi , . . . , Xk) where 
all the Xi are distinct variables. 

The abstraction of a normalized program is obtained by replacing every atom 
by an abstract atom that depends on the analyzed property because it describes 
the relation that exists between the arguments of a successful call to the atom. 
In this article, we only consider the groundness property: a ground term is a 
term with no free variable. 



2.2 Abstract Compilation for Groundness 

Atoms of the form p{Xi, . . . , Xk) are abstracted into Pa{Xi, . . . , Xj.)- Atoms of 
the form Xq = f{Xi, . . . , Xk) are abstracted into. (Aq, [Xi, . . . , Xk]), which^ 
is true if and only if Aq (Ai A ... A A^). In particular,. (Aq, []) is logically 
equivalent to Aq = true. For groundness analysis,. (Aq, [Ai, . . . ,Xk]) can be 

read as Aq. ^ , Ai, . . . ,Xk . . . . . 

^ .... . . . . Atoms of the form X = Y are abstracted into. (A, [P]) 

The abstracted program is a Datalog program [RU95] with propositional 
constants true and false as computation domain. Computing all the answers 
of a Datalog program is a decidable problem. This property is crucial for the 
abstract compilation technique; the language of the abstract programs must be 
a decidable language. 

The abstracted program can be seen as defining formulas in Vos 

[CFW91,MS93]. Vos consists of positive propositional formulas. Here, , 

means that when all variables of a propositional formula are instantiated to 
true, the formula is equivalent to true. An alternative definition is that positive 
propositional formulas are built with connectives A, V, and <->. 



^ Actually, other authors do not use a list as second argument of iff. They rely on 
the ability of concrete Prolog systems to use the same identifier for functors with 
different arities: e.g., iff/1, ijf/2, iff/S, etc. Since this form of overloading is not 
generally handled in typed variants of Prolog, we aggregate the optional arguments 
in a list. Note that these lists do not change the computation domain. In particular, 
there is no variable of type list. 
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Let P be the following Prolog program: 
append{\\,L,L) . append{[X\Xsl],Ys, [X\Zsl]) ^ append{Xsl,Ys, Zsl) . 
reverse{[], []) . 

reverse{[X\Xsl],Ys) reverse{Xsl,Ysl) A append(Ysl,[X],Ys) . 

P is normalized (left column) and abstracted in Pa (right column). 
append{Xs,Ys, Zs) appenda{Xs,Ys, Zs) 

Xs=[]AYs = Zs . . {Xs, Q) A. (Ps, [Zs]) . 

append{Xs,Ys, Zs) <= appenda{Xs,Ys, Zs) 

Xs=[X|Xsl]A . (Xs, [X,Xsl]) A 

Zs = [X\Zsl] A . (Zs, [X, Zsl]) A 

append(Xsl,Ys,Zs\) . appenda(Xsl,Ys,Zs\) . 

reverse(Xs,Ys) ^ revers6a(Xs,Ys) ^ 

Xs = D A Fs = D . - (Xs, D) A- (Fs, D) . 

reverse(Xs,Ys) <= revers6a(Xs,Ys) <= 

Xs = [X|Fsl] A . (Xs, [X, Xsl]) A 

reverse(Xsl,Ysl) A reversea(Xsl,Ysl) A 

A=[X\AI]AA1 = [] A . (A, [F,^l]) A. (^1,[])A 

append(Ysl, A,Ys) . appenda(Ysl, A,Ys) . 

The minimal model of Pa gives the following set of facts, M(Pa): 

{ appenda(true, true, true), appenda(true, false, false), 
appenda{ false, true, false), appenda(false, false, false), 
reversea(true,true), reverscaifalse, false) }. 

This says in particular that the first argument of an answer to append is either 
ground or not, which is a trivial fact, and misses an important point. Namely, the 
first argument of an answer to append is always a proper list, which is not true 
of the other arguments. Note that though prescriptive typing forces all three 
arguments to be seen as lists, it does not force them to be proper list in all 
answers. This shows that typed analysis is not a trivial combination of typing 
and static analysis. 

Let B be the goal reverse([l], L). Its normal form is 
X = [Y\Z] A F = 1 A F = [] A reversea(X, L) 
and its abstraction Ba is - (X,\Y,Z])A. (F, []) A- (Z,\\) Areversea(X,L) . 
An approximation of the answer set results from executing Ba on M(Pa): 
{reversea(true, true)}. It says that all answers to goal reverse([l], L) are ground. 

For the sake of the combination with types, we give a slightly different view 
on the previous abstraction. The abstraction of an atom Xq = f(Xi, . . . ,Xk) 
into a goal- (Aq, [Xi , . . . , X}f\) corresponds to the following deduction rule: 

Al : Pi ... Xu-.Pk 

/(Ai,...,Afc):A.e[i.fc]^* 

In the case of lists, one can specialize this rule into the two following rules: 

Al : Pi A2 : P 2 

[A 1 IA 2 ] : Pi AP 2 \}-.true 
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2.3 Prolog Terms with Simple Types 

We describe AProlog types and a part of AProlog term formation rules as a 
way of building a typed version of Prolog. This allows a progressive introduc- 
tion to the typed analysis of AProlog. 

Simple types are generated by the following grammar: 

r ::= W I (1C, I ^ 

i 

where W and ICi are respectively type variables and type constants of arity i. We 
suppose that /Cq contains the constant o for the type of truth values. The arrow 
associates to the right. The rightmost type is called the . Type con- 
stants are declared as follows: kind r type type — > type. The number 

of arrows defines the arity of the type constant r. 

Simply typed first-order terms are defined as follows^: 

TOTt ■.■.= Ct I Ut 

TOTt ::= (TOr^.^t TOTt>) 

where Ct and lAt are respectively term constants and logical variables, all being 
of type t. The second rule generates , , - _ . . . Application is considered left- 

associative. Every logical variable X has a type inferred by a typing system. 
Every constant / has a type defined by a type declaration: e.g., type nil (list A). 
A constant is called a , .. . . . if its result type is o: 

e.g., type nilp (list A) — > o. 

The inference of types of variables is decidable when types of all constants 
(especially predicate constants) are known [M084]. The inference of types of 
predicate constants is also decidable if clauses are not subject to the . . 

. (i.e., - . y . ) [LR91]. According to this condition every 

predicate constant must occur under the same type in the head of every clause 
that defines it. When the head condition is assumed, the inference of the types 
of predicates is undecidable in general. 

In this article, we assume that all types are available, either via inference 
or via declaration, and we also assume that definitional genericity is enforced; 
this will help in proving the termination of the analysis (see Section 4). Bris- 
set and Ridoux adopt these conventions in their AProlog compiler [BR93], 
though Nadathur and Pfenning propose a typing scheme that rejects the head- 
condition [NP92]. 



2.4 Domain T’os with Types 

For typed analysis, we combine the domain Vos with types. We call this new 
domain Vost- The constants of this domain are built with values true and 
false and with type constants (defined in the program). We define a partial 
order relation, <, and an equivalence relation, =, on Vost- 

^ This is not the standard notation for Prolog. This Lisp-like notation has been chosen 
for compatibility with the AProlog part of this article. Moreover, the expression of 
the discipline of simple types is easier with this syntax because only one application 
is considered at a time. 
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Definition 1. {Vost) true G Vost false G Vost - , - 

. . T G !Ci Xj G Vost {t x\ ... Xi) G Vost 

(Equivalence relation, =) (tq true . . . true) = true 

{Ta Pi ... Pn) = (Ta Ql ■■■ Qn)-. Pi = Qi . * 

(Partial order relation, <) false < {ja Pi ... Pn) , Pi ■■■ Pn 

{^a Pi • ■ • Pn) ^ ('i~a Ql • ■ • Qn)~^ - Pi ^ Qi , - - I 

- P^<Q^. ... 



If there is a declaration kind pair type — > type — > type in the pro- 
gram, values {paira true true), {paira true false), etc, are in Vost- And 
if both pair and list are declared, then {lista {paira true false)) and 
{paira true {lista false)), etc, are in Vost as well. 

Vost with these relations forms a lattice whose least value is false and 
greatest value is true. Every time there is a type constant of arity greater than 
0, Vost is a lattice with an infinite height. We we will see in section 4 that it 
does not impede termination. More precisely, there are infinite increasing chains 
(e.g., false, {lista false), {lista {lista false)), ..., {lisff false), ■■■), but all 
decreasing chains are finite. 

Definition 2 (Lattice operations in typed Vos). 

ViUV2-- -■ y ... V ..... {v < Vi) /\ {v < V2) 

V1UV2- .. .. V . ... . (fl < f) A {V2 < v) 

Formulas of Vost are built with Vost constants, variables, and operators □ 
and U. They are positive formulas in the sense that if all variables of a formula 
are set to true, the formula is never equivalent to false. Since Vost is not a 
complemented lattice, there is no simple definition of a operation. 

Predicate, must be redefined to take into account the domain Vost- 

Definition 3. ( Xq [Xi, . . . , Xk]) "*= Aq = H A, 

iG[l,k] 



2.5 First Order Typed Groundness Analysis 

Let us first study the case of lists. The data type list is defined as follows: 
kind list type —>■ type . 

type [] {list _) . type ' A {list A) {list A) . 

These declarations represent the following deduction rules: 

Al : A A 2 : {list A) 

[] : {list _) [A 1 IA 2 ] : {list A) 

Now, we combine typing rules with deduction rules for groundness (see Sec- 
tion 3) such that the conclusions of new rules are lower (< order) than or equal 
to conclusions of typing rules, and if one of the groundness premises is strictly 
lower than a typing one, as well is the conclusion. 
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[] : {lista true) 



Xi : Ai X2 : {lista A2) 
[X1IX2] : {lista A\ n A2) 



X. : Pi X, : P2 



if VP[Pi < P] V VP[P2 < {lista P)] 



[X1IX2] : false 

Since false is the least value of Vosr, we can replace the last rule with: 

if Pi < false V P2 < {lista false) 

[A1IA2J : false 

Constraint Pi < false cannot be satisfied, and the second one simply says 
P2 = false. However, in the sequel, we prefer to use forms similar to Pi < false 
and P2 < {lista false) for the sake of generalization. 

We can easily generalize these deduction rules to all the first-order constants, 
type c Ti ^ ^ Tk ^ {t Ti ... T„), where n, . . ., Tk and (r Ti ... T„) 

are either basic types {int, float, string, etc), or constructed types {{list A), 
{pair A B), etc). Every declaration of a term constant corresponds to three 
deduction rules: the usual typing rule, a static analysis rule that propagates 
groundness, and a static analysis rule that propagates non-groundness. These 
rules are as follows: 

Xi : Ti . . . Xk '■ Tk , . 

typing 



(c Xi 



■ ■■ Xk) 
Xi : Ti 



(tTi 



.. T„) 

Xk-.T! 



{cXi ... Xk) : {Ta (nPi) . . . (np„)) 



groundness 



where rj (j from 1 to k) are copies of types Tj where all occurrences of all 
variables are renamed apart. Ri is a list of all the renaming variables of Ti in 
the rj’s (j from 1 to fc). In the example of lists, the list of renaming variables of 
A is [Ai , A2] . 

Non-groundness propagation rules are as follow: 

Xl ■ Pi ... Xk ■■ Pk -r \l (p ^ 



non-groundness 



{c Xl ... Xk) : false 

where Pt are new variables, one per argument of c, and t" are instances of Tj 
where all variables are replaced with false. The general scheme can produce 
unsatisfiable constraints Pi < false; and this allows in practice to forget rules if 
none of their premises can be satisfied. 

Note that concrete programs are supposed to be well-typed, so all occurrences 
of a constant have types which are instances of its type scheme. So, the reason 
why a constraint like Pi < r" fails cannot be that Pi is not comparable with r". 
The only reason Pi < r" can fail is that Pi > r". 

Abstraction procedures for declarations of type and term constants are as 
follows: 



Definition 4. (Abstraction of type constant) 

Abstrkindlkind t type . . .type} = type Ta Post 



. . Post 



(Abstraction of term constant) 

Ahstrtype\type c n -> . . . ^ ^ (r Ti 

type. _T_ Po.ST {list Post) — 



T„)l = 
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. _r_ (to Ti . . . Tn) , . . . , r^] 4= . Ti A . . . A. T„ i?„ . 

- _r_ false [Pi, ...,Pk] <^= P\ < Pf V . . .V Pu < r'f . 

The following example shows one application of this method to a more com- 
plex type (trees with varisized nodes). 

Concrete declarations: 
kind ntree type — > type — > type . 
type leaf L — > {ntree N L) . 

type node {list {ntree N L)) ^ N ^ {ntree N L) . 

Their abstractions (where unsatisfiable premisses are underlined): 

- - - - , {ntreea Nq Lq) [Li] <= . Lq [Li] . 

. _ . _ , false [Pi] 4= Pi < false . 

- - - {ntreea No Lq) [{lista {ntreCa Ni Li)),N 2 ] <J= 

Lq [Ti] A- No [lVi,iV2] . 

. _ . _ . false [Pi,P 2 ] 

(Pi < {lista {ntreCa false false)) V P 2 < false) . 

The abstraction procedure for first-order terms is given below {<!> is a term 
constant). 

Definition 5. (Abstraction of equalities with term constants) 

AbstrgaailF ={<p Xi...Xk)j =. -T.<P F[Xi,...,Xk] 

, - - {tTi ... T„) 

(Abstraction of equalities without term constants) 

AbstrgaailF = xj =. F[X] X. .. 

The definition of Abstrgoai must be completed to handle connectives, and an 
Abstrdause procedure must also be defined. They are straightforward, and we 
lack of space for presenting them in more details. 

Let us apply this method to program append (see definition and 
normal form in Example 1). The abstraction of this program gives the following 
result: 

type appenda Post — *■ Post — > Post — *■ o . 

appenda Xs Ys Zs 4= - Xs [] A- Ys [Zs] . 

appenda Xs Ys Zs 4= 

- _ — As [A|Asl] A- . Zs [X[Zsl] A appenda XslYs Zsl. 

The set of success patterns of program appenda is as follows: 

{ appenda true true true, appenda {lista false) {lista false) {lista false), 
appenda true {lista false) {lista false) , 
appenda {lista false) true {lista false) , 

appenda {lista false) false false , appenda true false false } 

Note that this set does not contain atoms like {appenda false ). This is 

because predicate append either goes through or constructs an entire list in its 
first argument. Hence, the first argument of every answer to append is a proper 
list. Note that typed analysis is not merely a product of type inference/checking 
and static analysis in Vos. For instance, an argument can be a list, and still have 
property false (e.g., second and third arguments of append). 
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3 Typed Properties for AProlog 

The study of static analysis for AProlog programs was our original motivation 
for elaborating a typed static analysis simply because types are there. We show 
in this section what typed analysis of groundness looks like for AProlog. 

3.1 AProlog 

AProlog terms are .A. , . Simple types are generated as written 

above (see Section 2.3). Simply typed A-terms are defined as follows: 

At ::= Ct \ Vt \Ut\ {Af^t Ar) 

Af^t '■'■= AVt'At 

where the notations are as for simply typed first-order terms (see Section 2.3), 
and Vt is a set of A-variables of type t for all t. The novelty is essentially in the 
second rule, which generates A ... _ . . An occurrence of a A- variable x is 

called , . - if and only if it occurs in a A-abstraction Xx{E)\ otherwise, it is 
called , 

The leftmost component in nested applications is called the . . of the outer- 

most application. The notion of head is extended to non-applications as follows: 
the head of either a constant, a logical variable or of a A- variable is itself, and 
the head of a A-abstraction is the head of its body (recursively, if the body is 
itself a A-abstraction). 

An equivalence relation on A-terms, the A-equi valence, is defined by three 
axioms: 

or. \x{M) is a-equivalent to \y{M[x <— y]), if y has no occurrence in M. 
This formalizes the safe renaming of the A-variables of a term. 

/3: {Xx{M) N) is /3-equivalent to M[x ^ TV], if no free variable of N is 
bound in M. This formalizes the safe substitution of an effective parameter N 
to a formal parameter x. 

Tj: Xx{M x) is ry-equivalent to M, if x has no free occurrence in M. This 
formalizes functional extensionality for A-terms: two functions are equivalent if 
they yield equivalent results. 

When oriented left-to-right, axiom j3 forms a rewriting rule called /3-reduction. 
Oriented right-to-left, axiom y forms a rewriting rule called ry-expansion. Terms 
that match the left-hand side of the /3-reduction rule are called /3-redexes. A 
term with no occurrence of a /3-redex is called /3-normal. In the simply typed 
A-calculus, every term has a unique /3-normal form, which can be computed by 
applying the rules in any order. 

AProlog formulas (called , , , , ) are based on three 

hierarchical levels (like Prolog): definite clauses (2A), goals (^) and atomic 
formulas (Al). A AProlog program is a set of declarations and an ordered set 
of clauses. Clauses and goals are generated by the following grammar: 



V 


■= A \ A^g \ yx.v 


1 VXV 


g 


■■= A \ g xg \ gyg \ 


3x.g Wx.g \ V g 


A 


:= atomic formula 
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The novelty of Harrop formulas is in the goal language: universal quantifications 
and implications may occur in goals, which is forbidden with Horn formulas. 

In AProlog, there are three different notions of scope: A-abstraction limits 
the scope of variables in terms, quantifications limit the scope of variables in 
formulas, and the deduction rules (see below) for universal quantification and 
implication limit the scope of constants and clauses, respectively, in the proof 
process. 

P,iAhG PhG[x^c] ..u ■ o ■ ^ 

p ^ ^ Q — P \-\/ — G — occurs neither in P nor in G 

In the implication rule a clause D is added to a program P for the proof of a 
goal G, and in the universal quantification rule, a . / constant c is added for 
the proof of G[x ^ c]. 

The following example illustrates an application of A-terms for represent- 
ing data-structures. It defines the reversal of functional lists (lists represented 
by functions so that nil, [1,2] and [A\B] correspond to \x{x), Ax[l,2|a:] and 
Xx[A\{B x)]). 

type fnrev {{list A) {list H)) ^ {{list A) {list H)) ^ o . 

fnrev Xz{z) Xz{z) . fnrev Xz[A\{L z)] Xz{R [A\z]) fnrev L R . 

The first clause reverses empty lists, represented by the identity function. The 
second one uses higher-order unification to split a list and to construct another 
one. 



3.2 Groundness Analysis for AProlog Programs 

The normal form of AProlog programs extends the normal form for Prolog 
programs with additional rules for normalizing the new structures of AProloG: 
A-terms, quantifications and implication. Normalization for AProlog has the 
same goal as for Prolog programs. In particular, it makes unification steps 
explicit. 

The most important feature of normalized AProlog programs is that equal- 
ities have the form F = Xxi . . .xi{<P {X\ x\ ... xi) . . . {X^ x\ . . . xi)) where ^ 
can be either a constant (e.g., add), a bound A-variable (e.g., Xi, with i G [1, /]), 
or a logical variable. Moreover, all terms are 77 -expanded, so that the number of 
arguments of <P reflects its type. In Prolog/Mali (a AProlog system), type 
checking/inferring and ry-expansion are done anyway [BR93]. Every AProlog 
program can be transformed into an equivalent normalized form [MRB98]. 

A normalized form of predicate fnrev is as follows: 
fnrev C/0 G1 C/0 = Xx{x) A C/1 = Xx{x) . 
fnrev C/0 C/1 <;= 

C/0 = Aa;[(E0 x)\{El a;)] A EO = Aa;(A) A 

El = Xx{L {E2 x)) A E2 = Xx{x) A 

C/1 = Xx{R (E3 x)) A E3 = Xx[{E4 x)\{E5 a:)] A 

E4: = Xx{A) A E5 = Xx{x) A fnrev L R . 
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The aim of groundness analysis for AProlog is to determine which argu- 
ments of which atoms are instantiated to terms that are /3-equivalent^ to ground 
terms when the program is executed. The main difference with Prolog is the 
handling of A-terms. A A-term has two roles with respect to groundness: it may 
be ground, and it may propagates the non-groundness of its arguments to its 
/3-normal form. 

Let First = Xxy{x) be a A-term: First is ground. Now, let 
G = {First 1 X) and FI = {First X 1): G and H are ground terms if and only 
if X is ground. However, G /3-reduces to a ground term whereas /3-reduces 
to a ground term if and only if X does so. So, the behaviors of G and Ft are 
different . 



The way a A-term propagates the analyzed property must be represented 
somehow. We call it the . . of a A-term. So, we associate with 

First a transfer function which says that the first argument is propagated but 
not the second. Such a transfer function can be represented by a boolean vector 
that indicates which arguments are actually used. For reasons of convenience, 
we will code these boolean vectors as boolean lists. So, the transfer function of 
term First is represented by [t, f] . 

The transfer function of a given term is also used to compute the transfer 
functions of other terms in which it occurs. It is done by the means of a dis- 
junction of transfer functions. Given a term F = \x\ . . .xi{<l> {X\ x\ ... x{) . . . 
{Xk x\ ... xi)), the transfer function of X is a function of the transfer functions 
of and the Xi’s. Roughly, F needs its /th argument if either is its ith bound 
variable (i.e., Xi), or if it is needed by an Xj that is itself needed by <l>. 



Definition 6 (Disjunction of transfer functions). 

{ho.disj Ftf <P, <Ptf [Xuf , . . . , Xk,,]) Ftf = V V X,,^ 

36[lA]|4>t/j =t 



V-. 



We define a predicate . - that plays the same role as predicate - , ex- 
cept that it uses a transfer function for filtering out the properties of useless 
arguments. Roughly, a term F = \x\ . . .Xi{<P {Xi X\ ... xi) . . . {X}. X\ . . . xi)) 
/3-normalizes into a ground term if <P is not a logical variable, and if all the Xj ’s 
that <1> needs also /3-normalize into ground terms. 

Definition 7 (Relation . . ). 

(. - F, [Xi„ , . . . , XfcJ) Fa = <Pa/\ A 

The heart of abstraction is described by the abstraction of equalities. 

® Only /3-equivalence matters since ry-equivalence only concerns occurrences of A- 
variables {Xx{M x) =n M). /3-Equivalence matters because the argument N may 
either occur or not in the /3-reduced term according to whether the A-variable x 
occurs in the body M of the function {{Xx{M) N) =/3 M[x <— N]). 
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Definition 8 (Abstraction of equalities). 

Abstrgoai\F = xi{^ {Xi xi ... xi) . . . {Xk xi . . . a:z))] = 

- Fa ^tf [^la : ■ • ■ ; ^ HO-disj Ftf ^ , . . . , 



. 

. 

. 



constant 
A- variable 
unknown 



<Pa = true 
<I>a = true 




<P 



V 




0 

^1) 







i—1 l—i 




If we apply this method to predicate fnrev (see normalized form 
in Example 5), we obtain the following abstract program for the property of 
groundness, 

fnreva UQa UQtf Ula UUf <= 

. - UOa true [] [] A ho-disj UOtf [t] [] [] A 

. - Ula true [] [] A ho-disj Ultf [t] [] [] . 

fnreVa UQa UOtf Ula UUf <= 

. - UOa true [t,t] [E0a,Ela] A ho_disj UOtf [/] [t,t] [EOtf, EUf] A 

. - EOa Aa 0 [] A ho.disj EOtf [/] [] D A 

. - Ela La Ltf [E2a\ A ho.disj EUf [/] Ltf [E2tf] A 

. - E2a true [j [] A ho-disj E2tf [t] [] [] A 

. - Ula Ra Rtf [ESa] A ho.disj U Uf [/] Rtf [E^tf] A 

. - ESa true [t,t] [E4,a,E5a] A ho.disj E3tf [/] [t,t] [EUf,Ebtf] A 

. - E4a Aa [] [] A ho.disj EUf [f] [] [] A 

. - E5a true [] [] A ho.disj Ebtf [t\ [] [] A fnreVa La Ltf Ra Rtf ■ 
and finally a set of abstract answers, 

{ fnreVa true [t] true [t], fnreVa false [t] false [t] }. 

This result shows that both arguments of fnrev are unary functions that use 
their argument, and that an argument of fnrev is ground whenever the other is 
also ground. 



3.3 Higher Order Typed Groundness Analysis 

Let us consider the case of lists and then generalize as in Section 2.5, but in a 
higher-order context. 

In a normalized program, the form of every goal with an occurrence of a list 
constant is either F = Axi. .. x;[] or F = Axi. .. x;[(Ai xi ... xi)\{X 2 x\ ... xi)]. 
All equalities whose right member does not contain a list constant are abstracted 
by . - and equalities with list constants are abstracted with specialized pred- 
icates. 

To compute groundness, we need the transfer function of E and the trans- 
fer function of the head of the application (which, in this case, is either nil or 
cons). The transfer function of nil is [] whereas the transfer function of cons is 
[t,t] because cons uses its two arguments. The transfer function of \x\ . . .cci[] 
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is /] because none of the Xi’s occurs in the body of the abstraction. 

i 

The transfer function of Xx\ . . . xi[{Xi x\ ... Xi)\{X 2 x\ ... a;;)] is a disjunc- 
tion between the transfer function of X\ and the transfer function of X 2 ', i.e., a 
A- variable Xi occurs in the /3-normal form of this term only if it occurs in the /3- 
normal form of either {Xi x\ ... xi) or {X 2 X\ ... xi). The non-typed analysis 
presented in Section 3.2 needs also know whether the head of the application is 
ground or not. In the present case, the head is ground since it is a term constant. 
To summarize, the abstraction of equality goals where the head is a constant falls 
in the first case of definition 8. I.e., transfer functions play no role in these goals, 
so we will use. — .JP predicates instead of the expected . * . Jp. Then, the 

procedure for abstracting equalities is as follows: 

Definition 9 (Abstraction of equalities). 

- - (r Ti ... T„) 

AhstTgoallF = \xi... Xi{<P {Xi Xi ... Xi) ... {Xk Xi ... X;))]] = 

- JTJP Fa [Ai„ , . . . , XkjAhojIisj Ftf [ /, ■ , /J , . . . , Xk,j] 

l k 

/ -- <P <Py . <Ptf - - 

AbstrgoailF = Xxi... xi{<P (Xi xi ... xi) . . . {Xk xi . . . x;))]] = 

- - Fa <P a ■ ■ ■ T^ka] Aho-disj Ftf (Py <Ptf [Xitf, ■ ■ ■ 

Predicate . ^ is still used to abstract equalities whose head is not a con- 
stant. We give its definition with respect to Vosr. 

Definition 10. (. . ^t f , . . . , = <?, n H 

i^[l,k]\'Ptfi=t 



Let us analyze program fnrev with our new definition: the normal- 
ized program is as in Example 7, and the abstracted program is as follows: 
type fnreva Vosr — *■ [list bool) — > Vosr [list bool) o . 
fnreva C/Oa t/O*/ Ula Uhf <= 

. - UOa true [] [] A ho-disj UOtf [t] [] [] A 

. - Ula true [] [] A ho-disj Ultf [t] [] [] . 

fnreva UOa UOtf Ula Ultf <= 

. dist-cons UOa [EOa^Ela] Aho-disj UOtf [f] [t,t] [FOtf, Eltf] A 
. - EOa Aa Q [] A ho-disjE 0*/ [/] [] Q A 

. - Ela La Ltf [E2a] A ho.disj Eltf [/] Ltf[E2tf] A 

. - E2a true [] [] A ho-disj E2t / [t] [] [] A 

. - Ula Ra Rtf [ESa] A ho.disj Ultf [f] Rtf [E3tf] A 
. JisEcons E3a [E4:a,E5a] A ho-disj E3tf [/] [t,t] [E4:tf,E5tf] A 
. - E4a Aa 0 0 A ho.disj EAtf [/] [] [] A 

. - Eba true [] [] A ho_disj Ebtf [t] [] [] A fnreVa La Ltf Ra Rtf ■ 

We obtain a set of success patterns which takes into account the structure of 
lists: 

{fnreVa true [t] true [t],fnreva {lista false) [t] {lista false) [t]} . 
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We can compare these results with those obtained with the non-typed groundness 
analysis (Example 7). With typed analysis, {fnreva false [t] false [t]) is not a 
solution. This is because all the answers will be proper lists, even if the arguments 
passed to predicate fnrev are improper lists. 



4 Termination and Correctness 

The lattice Vosr has an infinite height in all non-degenerated cases. In this 
section, we show that it does not impede the termination of the analysis. 

The reason comes from the hypothesis that programs are type-checked be- 
fore being analyzed, that they follow the discipline of simple types and the poly- 
morphism discipline of definitional genericity [LR91] (related to the so-called 
. [HT92]), and that all decreasing chains in Vosr are finite. 

The first hypothesis essentially implies that a type is associated to every 
component (constants or variables) of a clause. The second hypothesis implies 
that all occurrences in clause heads of a predicate constant have equivalent 
types, and that all other occurrences (i.e., in clause bodies) have types that are 
either equivalent to or more instantiated than the types of head occurrences. 
This condition implies among other things that no type information goes from 
a called predicate to a calling goal. 

Let the following predicates p and q: 

pX ^ p[X]. q[X] ^ qX . 

p is definitionally generic (e.g., give type A o to p), but q is not. In- 
deed, whichever type is given to q, the type of the head occurrence is either not 
compatible or is strictly more instantiated than the type of the body occurrence. 

Thus, every component of a clause is equipped with a simple type that 
may contain type variables as a trace of polymorphic declarations. The head- 
condition insures that the types of most-general answers, like those computed 
by the S-semantics [FLMP89] for Prolog, or by a similar semantics defined for 
AProlog [Mal99], are not more instantiated than the type of their predicate. 

Finally, conclusions of typed analysis rules are either true, or lower than or 
equal (in the < order of Definition 1) to conclusions of the type rules from which 
they are derived. The typed analysis rules being applied to the same terms as 
the typing rules, they associate to terms properties that are either true, or are 
lower than or equal to their types. So, the answers computed by the S-semantics 
applied to the abstract program are on chains descending from the types of the 
clause heads. 

So, the effective domain of typed analysis is the set of type instances ob- 
tained by substituting true or false to type variables in types of all program 
components, plus all lower properties. It is a finite set, that could be represented 
as a set of constants, though this would not be suitable for comparing proper- 
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ties. Then, the domain of abstract programs can be assimilated with Datalog 
(Datalog^ for AProlog®). 

Proof of correctness derives from the observation that typed analysis rules 
are a refinement of non-typed analysis rules. In particular, one can prove by 
induction on typed and non-typed analysis rules that an abstract answer in the 
typed analysis is true only if it is also true in the non-typed analysis. 

Bonner has shown that Datalog^ is decidable, but he has also shown that 
answering queries in Datalog^ is in PSPACE [Bon90]. We do not know yet if 
this is an obstacle for the method we propose. 

5 Conclusion and Further Works 

Codish and Demoen have proposed a method for static analysis of PROLOG 
programs which is based on abstract compilation. They apply their method 
to the analysis of the groundness property. In preceding works [MRB98], we 
have proposed an extension of this method for the static analysis of AProlog 
programs. In this article, we augment the precision of informations obtained with 
analysis by combining the types of terms with the expression of the analyzed 
property. 

Our typed analysis is not a type inference. It is also different from Codish 
and Demoen’s analysis on types dependencies [CD94], which, in fact, is a form 
a type inference. More generally, as types are only a special kind of properties, 
it may seem vain to discriminate type inference and static analysis. However, 
a clear difference arises when one considers prescriptive types (which are not 
consequences of a program semantics), and semantic properties. This is what we 
are doing in supposing that polymorphic types are given, either via declarations 
or via inference, and we use them to build a property domain that is more refined 
than Vos. It is also important for the termination of evaluation of the abstract 
program that definitional genericity is enforced (see Section 4). 

To summarize, let us say that groundness analysis has to do with ground- 
ness, type inference/checking has to do with well-typing, and typed groundness 
analysis has to do with typed terms forming , , structures [O’K90]. Typed 

groundness analysis meets simple groundness analysis when a term and all its 
subterms are proper structures. 

The result of abstracting a AProlog program with respect to the typed 
groundness property is a Datalog^ program in which a finite set of constants 
is represented by complex terms. This language is decidable, so it makes sense 
to use it as the target of an abstract compilation method. In fact, the in- 
ferred/verified types form an envelop for the properties which can be reached in 
typed static analysis. 

The present work can be continued on different ways. First, one can apply 
it to other properties of Prolog and of AProloG: e.g., sharing. A list whose 



The => comes from implications in goals. For groundness analysis, universal quan- 
tifiers in goals do not remain in the abstract program, but implication connectives 
do [MRB98]. 
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elements share a subterm could be distinguished from a list that shares with a 
sublist. The second direction is to implement the method completely. At the 
present time, a prototype implements the normalization, the abstraction, and 
the evaluation when the abstract program contains no =>. Another direction 
is to handle function types directly in the abstract domain rather than via the 
transfer functions. This could lead to a smoother handling of higher-order terms. 
Finally, a more thorough analysis of Vosj- is also necessary. 
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Abstract. Tabled resolution improves efficiency as well as termination 
properties of logic programs by sharing answer computations across “sim- 
ilar” subgoals. Similarity based on subsumption of subgoals rather than 
variance (i.e., identity modulo variable renaming) promotes more aggres- 
sive sharing, but requires mechanisms to index answers from dynamically 
growing sets. Earlier we proposed Dynamic Threaded Sequential Au- 
tomata (DTSA) as the data structure for organizing answer tables in 
subsumption-based tabling. Using a DTSA, we can retrieve answers one 
at a time from the table, strictly in the order of their insertion. Although 
DTSA performed very well, its space usage was high. Here we present an 
alternative data structure called Time-Stamped Trie (TST) that relaxes 
the retrieval order, and yet ensures that all answers will be eventually 
retrieved. We show that TST has superior space performance to DTSA 
in theory as well as practice, without sacrificing time performance. 



1 Introduction 

Tabled resolution methods in logic programming (LP), beginning with OLDT 
resolution pioneered by Tamaki and Sato [10], address the well-known shortcom- 
ings of the SLD evaluation mechanism of Prolog, namely, susceptibility to infinite 
looping, redundant subcomputations, and inadequate semantics for negation. 
Using tabled resolution we can finitely compute the minimal model for datalog 
programs. More recent methods [1,2] compute well-founded semantics [11] for 
normal logic programs. Due to this added power, tabled evaluation enables us 
to combine LP, deductive databases, and nonmonotonic reasoning, and develop 
complex applications requiring efficient fixed point computations (e.g., see [7,6]). 

The power of tabled resolution stems from one simple notion: avoid redundant 
computation by permitting the use of proven instances, or answers, from past 
computation for satisfying new subgoals. This is achieved by maintaining a . , 
of the called subgoals paired with the set of answers derived for each such subgoal 

* This work was supported in part by NSF grants C-CR 9711386, C-CR 9876242, 
and EIA 9705998. 

** Currently at Telcordia Technologies (prasadr@research.telcordia.com); work 
done while at Stony Brook. 
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(known as answer tables). When a subgoal is selected for resolution, it is first 
checked against the entries maintained in the call table. If there exists a “similar- 
enough subgoal”, then its associated answers are used for resolving this subgoal 
( ^ - . ). Otherwise the subgoal is entered in the call table, and its 

answers, computed by resolving the subgoal against program clauses ( y 
_ ) are entered in the corresponding answer table. 

There are two approaches to locate a “similar-enough” goal. One approach, 
used by the XSB system [8], is to look for an entry that is a variant of the 
current goal, i.e., identical modulo variable renaming. Although variant-based 
tabling has been highly successful, this approach permits only limited sharing of 
answer computations. 

The second alternative, called , . , , _ tabling, permits greater 

reuse of computed results. Notice that, given a goal G, any entry in the table, say 
G', which G will contain in its final answer set all the instances to sat- 

isfy G} Using the answers of G' to resolve G avoids computationally-expensive 
program resolution, and thereby can lead to superior time performance. Space 
performance may also improve as fewer calls and their associated answer sets 
need be stored in the tables. However, the mechanisms for efficiently representing 
and accessing the call and answer tables are more complex. In particular, answer 
resolution now involves indexing, since not all answers in a selected answer table 
(say, that of G') may be applicable to the given goal (say, G). This process is 
especially challenging since all answers to G' may not yet be present in the table 
when the call to G is made. 

In an earlier work [9] , we proposed a data structure called Dynamic Threaded 
Sequential Automaton (DTSA) for representing and retrieving terms from dy- 
namic answer sets. Answer resolution is performed one tuple at a time by back- 
tracking through a DTSA. To ensure that every relevant answer is visited, an- 
swers are retrieved strictly in the order of their insertion into the table. Although 
an implementation based on this strategy shows improvement in time perfor- 
mance on queries where the subsumption of calls is possible, it performs poorly in 
space when compared to the variant-based tabling engine: potentially quadratic 
in the size of corresponding tables constructed in a variant-based tabling engine. 
Moreover, the incremental traversal of the DTSA for resolving each answer forces 
us to maintain complex state information, thereby increasing choice point space. 

In this paper we describe an alternative approach for answer resolution. We 
tag each answer with a time stamp and store them in . , . , , _ . ( ) 

which provides indexing based on the symbols in terms as well as the time stamp. 
Answers relevant to a call are periodically collected from the subsuming call’s 
answer set and cached locally (by the subsumed call) for later consumption. The 
local cache is updated whenever all answers currently held in the cache have 
already been resolved against the goal. Each collection phase completely searches 
the set for answers which have been entered since the previous phase, selecting 
only those answers which unify with the subsumed goal. Since a complete search 



^ A term ti subsumes a term if t2 is an instance of ti. Further, ti properly subsumes 
t2 if ti subsumes t2 and ti is not a variant of t2- 
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is done in each phase, only minimal state information — the time stamp of the 
last update — is needed between collection phases. The tables stored as TSTs are 
at most twice as large as the tables in the variant engine, and at most as large 
as the tables in our earlier DTSA-based engine. Moreover, the space efficiency 
comes with little or no time penalty. 

The rest of the paper is organized as follows. In Section 2, we present an 
operational overview of tabling operations and answer resolution in subsumption- 
based tabling. The design and implementation of TSTs appears in Section 3. 
Comparisons between DTSA, TST and variant-based tabling engines appear in 
Section 4. In Section 5 we provide performance results of a subsumption-based 
tabling engine implemented using TSTs. 

2 Answer Clause Resolution via Time Stamps 

Below we give an overview of the time-stamp-based subsumptive tabling engine. 
We begin with an abstract description of the operations of a tabling system. 



2.1 An Overview of Tabling Operations 

We can view top-down tabled evaluation of a program in terms of four ab- 
stract table operations: . - ., / . - ., ^ 

and . - y ^ . Below, we describe each of these operations in the context 

of subsumptive tabling. 

- . Given a call c, the . - . operation finds a call d 

in the call table that subsumes c. If there is no such c', then c is inserted into 
the call table. Note that . - . .is independent of the data structures 

used to represent answer tables. 

A subgoal that is resolved using program creates answers to be inserted into 
the corresponding answer table, say T, and is known as the ... of T. 
A subgoal that is resolved using answer resolution with respect to an answer 
table T is known as a of T. 

/ . - . This operation is used to add the answers computed for a 

calll into its corresponding answer table. The operation ensures that the answer 
tables contain only unique answers. Note that, while the data structures used 
to represent answer tables may be different between subsumptive and variant 
tabling, the requirements on . . ^ . . . . remain the same. 

. . / Answer clause resolution of a call c against a set of terms 

T = ■ ■ ■ ,tn} in an answer table produces a set R such that r G i? iff 

r = tiOi for some U, where 9i = . This resolution is performed using 

... ^ operations. In a tuple-at-a-time resolution engine, a 

, - . is placed so that the answers can be retrieved one by one using 
backtracking. To ensure that an answer is returned at most once, we maintain an 
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/ _ , _ in the choice point, which represents the set of all answers 

remaining to be retrieved. Hence the arguments supplied to a . - , / 

operation is split naturally into: 

~ - - / Given an answer table T and a call c, return an answer from 

T that unifies with c, and an answer continuation. 

~ . _ / Given an answer table T, a call c, and an answer continuation 

7, return the next answer a from T that unifies with c as specified by 7, and 
a modified answer continuation 7' that represents the remaining answers. 

y . . / Answer continuation _L denotes that there are no more re- 
maining answers. When a . - , . / operation for a call c on an incom- 

plete table T returns _L, the call c will be suspended. The suspended call is 
later resumed when new answers have been added to T, or when T is known to 
be complete. Suspension and resumption of calls are performed by the answer 
scheduler which invokes, - > / to determine whether a suspended call 

needs to be resumed. Given an answer continuation, , > / succeeds 

iff the continuation represents a non-empty set of answers. 

2.2 Answer Retrieval in Subsumptive Tabling 

The DTSA, proposed as a data structure for answer tables in [9], directly sup- 
ports the . , , / and , . , , / operations. In this paper, we describe an 

alternate, two-tier mechanism to realize these operations. At the fundamental 
level, we decouple the operation of - , , y the answers relevant to a given 
goal in an answer set from the operation of, , y one of these answers with 
the goal. This separation frees the identification process from tuple-at-a-time 
execution. We hence propose an efficient mechanism to identify relevant an- 
swers that have been added since the last time the table was inspected. We 
associate a time stamp with each answer and maintain, as part of the answer 
continuation, the maximum time stamp of any answer in the set. These answers 
are stored in a TST and accessed using. / which, given 

a table T, time stamp r and goal G, identifies the set of all answers in T with 
time stamps y . .. r that unify with G. It returns this set as a list (with 

some internal order) as well as the maximum time stamp of any answer in T. 

Recall that answers are consumed from a table by a . _ / opera- 
tion followed by a sequence of . _ / operations. We can implement these 

tuple-at-a-time operations based on time stamps as follows. We assume that 
time stamps are positive (non zero) integers. To compute , . _ / , we use 

, / , with a time stamp of zero (thereby qualifying all avail- 

able answers), select one answer from the returned set as the current answer, 
and store those remaining in an internal data structure called an / . , . . 

The answer list, together with the maximum time stamp returned by . _ 

/ , form the answer continuation. On subsequent invocations 

of , . _ ^ , we simply manipulate the answer list component of the continu- 

ation, as long as the answer list is not empty. Should the answer list be empty, we 
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“refresh” the continuation by another call to. _ _ , - _ . _ ^ , using the 

time stamp component of the continuation to restrict identification to only those 
answers that have been inserted since the last call to. _ / 

Let r be the time stamp returned by an invocation of the access function 
-_ y . Since this operation identifies relevant answers, 
([ ],r) represents the empty continuation, _L. Note that the continuation, ([ ], 0 ), 

that represents all answers in a table. Thus, . / (T, c) can be realized 

simply as / (T, c, ([ ], 0)). 

The method described above can be formalized readily; see [ 5 ] for details. We 
now state the requirement on. . / . that is needed to show 

the correctness of / and . / : 

Requirement 1 . / T , / S' 

y G - - . . , T identify _relevant_answers(T, G, r) . .. 

. . {a G S I a . - G . _ . . . (a) > r} 

The correctness of operation ... / is then ensured by the following 

proposition: 

Proposition 1. . y G / . , T . y . , 

/ S . (ai, 7 i),... ,(a„, 7 „) , (01,71) = 

first_answer(r, G) . (01+1,71+1) = next_answer(T, G, 71) /. 1 < i < n 

. 7„ = T = ([ ],r) ... . R . .. . {bGS \ b. . . .... G . 

, (6) > r} identify .relevant .answers _. 

(oi, . . . , an). . . - , . {b 9 \ b€ B ^ . 

e = . y, (&,G)} 

3 Time-Stamped Tries 

In this section we describe Time-Stamped Trie, which permits indexing on term 
symbols as well as time stamps. A TST represents a set of terms T and supports 
two operations: ( 1 ) Insert a term t into set T if not already present, and ( 2 ) 
Given a term t, determine the set of all terms t' £T that unify with t. Below we 
describe these operations formally. We begin by defining notational conventions 
and terminology and review answer tries described in [8]. 

A , . in a term is either the empty string A that reaches the root of 

the term, or tt.i, where tt is a position and i is an integer, that reaches the 
child of the term reached by tt. By we denote the symbol at position tt in t. 
For example, p(a, /(X))|2,i = X. Terms are built from a finite set of function 
symbols T and a countable set of variables V U V, where V is a set of 

variables and V is a set of , variables. The variables in the set V are of 

the form X,r, where tt is a position, and are used to mark certain positions of 
interest in a term. We denote the elements of IF U V by a. 

A . . is a tree-structured automaton used for representing a set of terms 
T = ■ ■ ■ ,tn}. A trie for T has a unique leaf state si for every U, 1 < 

i < n, such that the sequence of symbols on the transitions from the root to Si 
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p(a,a,a) 

p(b,a,W) 

p(a,a,c) 

p(a,b,b) 

p(a,a,d) 




p(a,a,a) p(a,a,c) p(a,a,d) p(a,b,b) p(b,a,W) 
1 3 5 4 2 



p(a,a,a) p(a,a,c) p(a,a,d) p(a,b,b) p(a,b,c) p(b,a,W) 
1 3 5 4 6 2 



(a) 



(b) 



(c) 



Fig. 1. Set of terms (a), its corresponding TST representation (b), and effect of 
inserting p(a,b,c) to the TST (c) 

correspond to the sequence of symbols encountered in a preorder traversal of U. 
Moreover, for every state in a trie, all outgoing transitions have unique labels. 
With each state s is associated a skeleton, denoted by s, that represents the 
set of unification operations that must be performed to reach that state. The 
fringe of ^ represents positions where further unification operations need to 
be performed before unifying a goal term with a term in T. The position in the 
goal term inspected at s is represented by the first position variable encountered 
in a preorder traversal of the skeleton. We denote this position by 7t(s). Each 
outgoing transition from s represents a unification operation involving position 
7t(s) in the goal and the symbol labeling this transition. We label transitions 
by a, where a is a variable or a function symbol. Let the position examined at 
the current state be tt. Then the skeleton of the destination state reached by 
a transition labeled by a is where t = . . . , Ai,r.n) if a is a 

n-ary function symbol / and t = a otherwise. Note that for a leaf state s in the 
trie, , - y ( s) is empty and that s € T is the term represented by s. 

A Time-Stamped Trie (see Figure 1) is a trie augmented with information 
about the relative time its terms were inserted. The time of insertion of each 
term is called its _ . . , . , and is represented by a positive (non zero) integer. 

Each transition in a TST is additionally labeled with the maximum time stamp 
of any leaf reachable using that transition. Hence, all transitions in a TST will 

be of the form s — hI, where s and d are states in the TST, a is the symbol, and 
T is the time stamp. We refer to these attributes of a transition <5 as symbol(S) 
and timestamp(S), respectively. Since.- / looks only for 

answers with time stamps greater than a given value, the , . . , , time stamp 

information on transitions is necessary to restrict the search on portions of the 
TST that correspond to answers with such time stamp values. 

3.1 Term Insertion into a TST 

Terms are inserted into a TST in a manner analogous to the single-pass check- 
insert for the trie representation described in [8] . The TST is traversed recursively 
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algorithm insert{s, t, r) 

(* returns true iff t was successfully inserted *) 
if ( fringe{Skels) = {} ) then 

return ( false ) (* term already exists, hence insert fails *) 

endif 

let G|^(s) = //n = a 

if ( 35 : ) then 

if ( inserted, t,r) ) then 

timestamp(5) = r (* insert successful, so update time stamp *) 

return ( true ) 
else 

return ( false ) (* insert failed; propagate failure up *) 

endif 

else (* match fails at s, so add a new path *) 
create new state d and add transition 5 : s^^^^d 

Skcld Skcl s [/* (s) . 1 7 ■ ■ ■ 5 (s) .ri)/'^7r (s) ] 

msert{d, t, r) 

return ( true ) 
endif 



Fig. 2. Term Insertion into a Time-Stamped Trie 



starting at the root. A transition from states s to d, s'—^d, is taken if the symbol 
a matches the symbol in the goal term at the position specified by s. If a leaf 
state is reached, then the term already exists in the set, and hence the TST 
is left unchanged. On the other hand, if a match operation fails at a state s, 
then a new path is added to the TST corresponding to the given term. All 
time stamps on the transitions along the root-to-leaf path corresponding to this 
term are updated with a value greater than any other time stamp in the TST. 
This recursive procedure is specified in Figure 2. The TST obtained from the 
one in Figure 1(b) by adding the term p(a,b,c) is given in Figure 1(c). The 
new transitions and states, as well as the transitions whose time stamps were 
modified by the addition, appear in bold face in the figure. 



3.2 Identifying Relevant Answers Using a TST 

We now describe how TST supports. / . Given a goal G 

and a time stamp r, answers in a TST, T, are identified by recursively traversing 
T from the root, at each state exploring all transitions that meet the term 
indexing as well as the time stamp constraints. The set of transitions to be 
explored can be formally specified as follows. 

Definition 1 (Set of Applicable Destinations). . . - , 

. T , . _ . . s 

- T /. .. y G - - . , T . . . dest(s, G, r) - , .... 
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d S dest(s, G, r) - - d. . . , /. .. G _ - . 

. T t' >T 

In the above definition, condition (i) corresponds to indexing on . . while (ii) 

corresponds to indexing on _ 

Given a state s in a TST, a goal G, and time stamp r, the set of all terms 
represented by the leaves reachable from s with time stamps greater than r and 
unifiable with G is given by: 

{ { s} if s is a leaf 

IJ . (d, G, r) otherwise 

d G dest(s,G,r) 

Finally, let T be a TST. Then, 

-- - / {T,G,r)= .( .(T),G,t) . 

We can establish that the above definition of - . - - - / meets 

Requirement 1. 

Proposition 2 (Correctness). . . . , . T _ y 

. , . S y G - - . T identify _relevant_answers(T, G, r) 

. . .. . {a G S' I a , . . . /. .. G . _ . . . (a) > r} 

Although one can readily derive a computation based on the above definition 
of- . . - . - _ / . , its effectiveness depends on the efficient implemen- 

tation of . ... It should be noted that the condition in . . . for indexing on terms 
is identical to the one with which transitions to be traversed are selected in a 
(non time-stamped) trie [8]. The indexing on time stamps, however, is unique to 
TSTs. We can show that - . . can be efficiently computed 

given an efficient technique to index on time stamps . ... in a TST, as 

formally stated below. 

Requirement 2 - - . . T Z\ = dest(s, G, r) - . . 

. - . . . |A| 

Propositions (Efficiency). . G, y - . /. - 

..... T . .... . 

identify _relevant_answers(T, G, r) - S,. y- . 

, T . dest _ , , - , . .. . S , 

- - -- - S 

The structure of TSTs do provide at each state, in addition to the normal 
index on symbols present in tries, an index on time stamps. Each time index can 
be maintained as a doubly-linked list of outgoing transitions - 
. . . . This organization allows us to select transitions based on time 

stamps alone, at constant time per selected transition, thereby satisfying Re- 
quirement 2. Moreover, by cross-linking the time and term indices, the time 
index can be updated in constant time as new transitions are created. Finally, 
note that TSTs support answer retrieval from. , . . answer sets the time 

index can be deleted when the answer table is complete. 
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Fig. 3. DTSA (a) and Trie (b) representation of terms in Figure 1(a) 



4 Comparison of Tabling Approaches 

We now compare variant- , TST-, and DTSA-based tabling engines. To provide 
the context for comparisons, we now briefly review the data structure called 
. _ , , . . (DTSA) that was used in our earlier 

implementation of a subsumption based tabling engine. 

The DTSA Structure. DTSA is a trie-like automaton for representing a set of 
ordered terms • ,tn}- A DTSA is constructed such that, in a preorder 

traversal, the leaf representing term ti is visited before the leaf representing 
term ti+i (Figure 3(a)). Since transitions from a state s preserve the order of 
terms represented by the final states reachable from s, there may be multiple 
transitions with the same label. The loss of indexing due to this duplication 
is offset by using .. _ which link states that share prefixes. For instance, 

using the DTSA in Figure 3(a) to And terms uniflable with a given goal term 
p(a,a,V), after finding the first term (at state S4), the next term, p(a,a,c), can 
be retrieved by backtracking to S3, following the thread to sg, and making the 
transition to Sig. Observe that both S3 and sg have pCa.a.Ag) as their skeleton. 

4.1 Shared Features 

The variant, DTSA- and TST-based subsumption engines share many common 
features. For instance all engines distinguish between , , . and- 
table entries. Completed answer tables are organized as , , - ... . in 

all of them (see [8] for details). Although incomplete tables are organized dif- 
ferently they all use substitution factoring whereby only the substitutions for 
the variables of the call are stored in the answer tries [8]. Once a table entry 
has completed, all structures created to support answer resolution from the in- 
complete table are reclaimed. These include the leaf node pointers, the auxiliary 
structures for indexing on time in the TST-based subsumption engine, and the 
entire DTSA itself in the DTSA-based subsumption engine. 

In the following, we focus on the differences between the three engines. 
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4.2 Variant- vs. TST-Based Engine 

Subsumption engines have a more complex call-check-insert operation than the 
variant engine. However, this adds very little (constant factor) overhead to the 
evaluation time. Due to sharing of answer computations, subsumption engines 
can show arbitrary gains in time performance. The interesting result is that the 
table space used by a TST-based engine is always within a constant factor of 
that used by the variant engine. In fact. 

Proposition 4 (Space Complexity of TST-Based Engine). . . 



This bound follows from the observation that a TST is structured like a trie with 
respect to the representation of the answers as sequences of symbols - i.e., a trie 
and a TST representing the same set of answers have the same number of nodes 
(states) - and that the size of a TST node is twice that of a trie node (including 
space for the time index). 

4.3 DTSA- vs. TST-Based Engine 

The subsumptive engines can be distinguished by their approaches to performing 
answer retrieval. Subsumption using Time-Stamped Tries divides this operation 
into two processes: (i) identifying answers relevant to a particular goal, and (ii) 
unifying a selected relevant answer with that goal. Identification of relevant an- 
swers is achieved by a complete search of the TST, yielding a . . of answers, 
as discussed in Section 3.2. In contrast, DTSA directly supports the primitive 
operations of answer retrieval, providing for simultaneous identification and con- 
sumption of a - y answer. 

Consequently, DTSAs have more complex continuations, requiring enough 
state information to resume the traversal; a continuation consists of a .of 
choice points, one for each level in the DTSA. On the other hand, since com- 
plete traversals of a TST are performed during each identification phase, only 
the maximum time stamp of all answers contained in the TST is required for 
subsequent processing. 

DTSA also consumes more table space than TST. In contrast to Proposi- 
tion 4, the maximum size of a table in the DTSA-based engine is . . . double 

that of the representation in the variant engine, as an answer trie (Figure 3(b)) 
is created in addition to the DTSA. Moreover, the number of nodes in a DTSA 
may be quadratic in the number of nodes in a corresponding TST. For example, 
consider the program depicted in Figure 4(a). Answers to the query a(X,Y) are 
discovered in such an order that no sharing of nodes is possible in the DTSA 
(Figure 4(b)). However, since answers are simply marked with the insertion time 
in a TST, rather than stored in derivation order, the resulting sharing makes 
the corresponding TST more compact (Figure 4(c)). It can be shown that the 
number of nodes required to represent the set of answers to the query a(X,Y) in 
the TST is n{n — l)/2 -|- 2k, whereas in the DTSA, the number of nodes required 
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table a/2. 

aCX,Y) p(X,Y). 
aCX,Y) 

pCX,Z), 
qCX,Z,W) , 
aCW,Y) . 

q(f(.),Z,g(h'=(Z))). 

q(g(.),Z,f(h'=(Z))). 

p(f(h'=(l)),2). 

p(g(h‘=(2)).3). 

p(f(h'=(3)),4). 



pCgCh*' (n-2) ) , n-1 ) . 
p(f(h'=(fi-i)),n). 

(a) 

Fig. 4. Program (a) and two organizations of the answer set for the query 
a(X,Y): That which would be produced for a DTSA (b) and a (Time-Stamped) 
Trie (c) 




is n{n — 1)(2 -I- fc). As can be seen from both the diagram and these expressions, 
the size of k adds but a constant factor to the size of the TST, whereas in the 
DTSA, its effect is multiplicative. 

5 Experimental Results 

We now present experimental results to compare the performance of the TST 
engine with that of the variant and DTSA engines. All measurements were taken 
on a SparcStation 20 with 64MB of main memory running Solaris 5.6. We present 
the results using the benchmarks presented in [8], derived from the programs: 
left-, right-, and double-recursive versions of transitive closure (lrtc/2, rrtc/2, 
drtc/2), and the same generation program (sg/2). We note that both the TST 
and DTSA engines were constructed from different base versions of XSB ~ the 
TST engine from version 1.7.2, and the DTSA engine from version 1.4.3. The 
measurements were made so as to minimize the impact of this difference dur- 
ing each experiment, as discussed below. Because the changes between to two 
versions did not grossly affect the method of evaluation — in particular, XSB’s 
scheduler — we feel that the following results accurately reffect the relative per- 
formance of the systems. 

Time Efficiency. The TST engine shows little overhead when the evaluation 
does not lead to subsumed calls. The overheads result only from the subsumption- 
checking . . . operation. As time-stamp indexes are lazily created, 

no penalty is incurred due to their maintenance. In addition, updating of time 
stamps along the path of insertion is avoided by assigning a time stamp value of 
1 to all answers entered before the first subsumed call is made. These optimiza- 
tions enable the TST engine to perform performing within 2% of the speed of 
the variant engine (see [5] for details). 
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Table 1. Speedups of DTSA and TST engines in evaluations involving 
subsumption 



Query 


Graph Size 


XSB 1.4.3 


XSB 1.7.2 


Variant 


DTSA 


Speedup 


Variant 


TST 


Speedup 


rrtc(X,Y) 


Chain 


512 


3.36 


3.44 


0.97 


3.05 


2.16 


1.41 






1024 


16.8 


13.8 


1.21 


14.6 


8.74 


1.68 




Tree 


2048 


0.48 


0.77 


0.62 


0.45 


0.37 


1.21 






4096 


1.06 


2.08 


0.51 


1.00 


0.83 


1.20 


drtc(X,Y) 


Chain 


128 


6.54 


4.60 


1.43 


5.88 


3.09 


1.90 






256 


52.0 


38.7 


1.35 


51.5 


24.1 


2.14 




Tree 


2048 


1.87 


1.91 


0.98 


1.72 


1.25 


1.38 






4096 


4.57 


4.86 


0.94 


4.24 


3.00 


1.41 


sg(X,Y) 


Chain 


512 


0.68 


0.06 


11.3 


0.64 


0.04 


15.8 






1024 


2.73 


0.12 


22.5 


2.58 


0.09 


27.5 




Tree 


128 


0.12 


0.14 


0.89 


0.11 


0.10 


1.10 






256 


0.49 


0.50 


0.97 


0.43 


0.43 


1.01 


lrtc(l,X) , 


Chain 


2048 


29.4 


0.13 


219 


27.5 


0.10 


277 


lrtc(2,X) 




4096 


118 


0.30 


392 


110 


0.20 


574 




Tree 


2048 


17.6 


0.10 


176 


17.3 


0.09 


190 






4096 


71.1 


0.20 


351 


69.7 


0.18 


388 



The performances of variant and TST engines differ when subsuming vails are 
made. Table 5 shows the execution times of the TST and DTSA engines relative 
to their base variant engines on examples with this behavior. We compare the 
performance of each engine using the speedups achieved over their base variant 
engines, thereby removing the noise in the results caused by differences in their 
base implementations. As each subsumptive engine merely extends the tabling 
subsystem to support subsumption, this method measures the performance gain 
achievable by each tabling approach. Notice that in all cases, the TST engine 
performs at least as well as the DTSA engine. 



Table Space Usage. In Table 5 we report on the memory utilized in repre- 
senting the tables for some of the benchmarks described earlier. This . . 
consists of the call and answer tables, where the latter consists of answer tries, 
TSTs, DTSA, and answer lists as present in a particular engine. We report the 
maximum space consumed . , - y evaluation, as well as the space consumed 
by the , . . tables. Table 5 is divided into three sections: the upper por- 

tion shows results for benches that do not make use of subsumption; the middle 
section shows results for benches for which properly subsumed calls consume 
answers only from incomplete tables; and the bottom portion shows results for a 
bench whose subsumed calls consume answers from completed tables only. The 
space used by the DTSA engine for completed tables is identical to that of TST, 
and therefore is not repeated. 
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Table 2. Space usage for tables in variant and subsumptive engines 



Query 


Graph Size 


Maximum Table Space 


Completed Table Space 


Variant 


DTSA 


TST 


Variant 


TST 


lrtc(l,Y) 


Chain 4096 
8192 


128 KB 
256 KB 


144 KB 
288 KB 


144 KB 
288 KB 


96.1 KB 
192 KB 


112 KB 
224 KB 


rrtc(l,Y) 


Chain 512 
1024 


4.23 MB 
16.8 MB 


4.75 MB 
18.8 MB 


4.75 MB 
18.8 MB 


3.23 MB 
12.8 MB 


3.75 MB 
14.8 MB 


rrtc(X,Y) 


Chain 512 
1024 


7.41 MB 
29.5 MB 


9.89 MB 
39.1 MB 


7.73 MB 
30.8 MB 


6.41 MB 
25.5 MB 


3.73 MB 
14.8 MB 


Tree 2048 
4096 


1.23 MB 
2.68 MB 


1.64 MB 
3.58 MB 


1.23 MB 
2.69 MB 


1.09 MB 
2.36 MB 


702 KB 
1.48 MB 


drtc(X,Y) 


Chain 128 
256 


492 KB 
1.87 MB 


826 KB 
3.19 MB 


508 KB 
1.95 MB 


429 KB 
1.62 MB 


252 KB 
971 KB 


Tree 2048 
4096 


1.23 MB 
2.68 MB 


1.71 MB 
3.73 MB 


1.23 MB 
2.69 MB 


1.09 MB 
2.36 MB 


702 KB 
1.48 MB 


sg(X,Y) 


Chain 512 
1024 


88.1 KB 
176 KB 


110 KB 
220 KB 


84.1 KB 
168 KB 


84.1 KB 
168 KB 


60.1 KB 
120 KB 


Tree 128 
256 


231 KB 
855 KB 


430 KB 
1602 KB 


309 KB 
1190 KB 


188 KB 
685 KB 


168 KB 
629 KB 


lrtc(l,X) , 
lrtc(2,X) 


Chain 2048 
4096 


320 KB 
640 KB 


128 KB 
256 KB 


128 KB 
256 KB 


304 KB 
608 KB 


112 KB 
224 KB 


Tree 2048 
4096 


276 KB 
522 KB 


100 KB 
200 KB 


100 KB 
200 KB 


260 KB 
520 KB 


84.4 KB 
168 KB 



As mentioned earlier, the subsumptive engines exhibit a 20% overhead in the 
representation of answer tries as compared to the variant engine. For the benches 
which do not exhibit subsumption, observe that the actual increase appears lower 
due to the presence of the call table and answer lists in this measure, which are 
present in all engines. When answer lists are reclaimed upon completion, the 
space overhead approaches 20%. 

The query lrtc(l,X) ,lrtc(2,X) exhibits behavior similar to nonsubsump- 
tive evaluations during construction of the tables as subsumed calls do not occur 
until the tables complete. This allows both subsumptive engines to avoid con- 
structing their respective subsumption-supporting data structures. Since answer 
tables are shared, the subsumption makes the subsumption engines consume less 
maximum and final spaces than the variant engine. 

For those queries which utilize subsumption from incomplete tables, only a 
single table is constructed under subsumptive evaluation - that of the origi- 
nal query. This table expands throughout the computation until it completes, 
terminating the evaluation. Under variant evaluation, however, several tables 
are constructed in addition to the one for the query itself, but are completed 
incrementally during the computation. Therefore, memory usage is somewhat 
amortized as space is periodically freed by the tables as they complete. The rel- 
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Table 3. Maximum choice point space usage for various tabling engines 



Query 


Graph Size 


Variant 


DTSA 


TST 


lrtc(l,Y) 


Chain 4096 
8192 


0.61 KB 
0.66 KB 


0.61 KB 
0.66 KB 


0.61 KB 
0.66 KB 


rrtc(l,Y) 


Chain 512 
1024 


36.5 KB 

72.5 KB 


36.5 KB 

72.5 KB 


36.5 KB 

72.5 KB 


rrtc(X,Y) 


Chain 512 
1024 


36.5 KB 

72.6 KB 


100 KB 
208 KB 


30.5 KB 

60.5 KB 


Tree 2048 
4096 


1.64 KB 
1.81 KB 


288 KB 
592 KB 


120 KB 
240 KB 


drtc(X,Y) 


Chain 128 
256 


16.4 KB 

32.5 KB 


494 KB 
1950 KB 


477 KB 
1913 KB 


Tree 2048 
4096 


1.76 KB 
1.94 KB 


1.22 MB 
2.69 MB 


1.06 MB 
2.34 MB 


sg(X,Y) 


Chain 512 
1024 


0.71 KB 
0.77 KB 


100 KB 
208 KB 


30.5 KB 

60.6 KB 


Tree 128 

256 


0.76 KB 
0.82 KB 


16.5 KB 
33.7 KB 


7.93 KB 
15.5 KB 


lrtc(l,X) , 
lrtc(2,X) 


Chain 2048 
4096 


0.74 KB 
0.80 KB 


0.74 KB 
0.80 KB 


0.74 KB 
0.80 KB 


Tree 2048 
4096 


0.78 KB 
0.84 KB 


0.78 KB 
0.84 KB 


0.78 KB 
0.84 KB 



ative performance in maximum space usage between the two tabling paradigms, 
then, depends not only on the amount of answer sharing that is possible - and 
so the extent to which duplicity can be avoided - but also on the pattern of table 
completion. For these queries, only sg(X,Y) on chains exhibits conditions dur- 
ing the evaluation which are conducive to savings under subsumption, and that 
by using TSTs only. However, as Table 5 also shows, in subsumptive cases 
(middle and lower portions of the table) the TST engine yields a more compact 
representation of the , , . . . , , even though each TST consumes more 

space than the corresponding answer trie in the variant engine. 

Finally, for all queries where subsumed calls are resolved only with incom- 
plete tables, the TST engine outperforms the DTSA engine in maximum space 
required as predicted (Sect 4.3). The results show that the amount of savings can 
be significant, in absolute (see rrtc(X,Y)) or relative terms (see drtc(X,Y)). 

Choice Point Creation. In Table 5 we present maximum choice point stack 
usage which, together with table space usage, accounts for most of the total 
memory used during query evaluation with subsumption. As the sizes of producer 
and consumer choice point frames differ between the versions of XSB, we have 
added padding to these structures to normalize the values and enable a direct 
comparison. For this reason, only results from one version of a variant engine is 
shown in this table. 
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As compared to a variant based evaluation, choice point space is likely to in- 
crease as subsumed calls are dependent upon the more general goal, and there- 
fore cannot complete before the general goal itself is completed. Hence, the 
corresponding consumer choice points must remain active on the choice point 
stack. In contrast, under variant evaluation, the more specific goals are resolved 
by program resolution, independent of the more general call, and hence have 
the opportunity to complete earlier and free stack space for reuse. Note that 
the former condition is a characteristic of subsumption-based query evaluation 
rather than any particular implementation of the tables. In particular, for the 
query drtc(X,Y) executed on trees of depth fc, it can be shown that the maxi- 
mum number of concurrently active choice points is equal to the number of calls 
to drtc/2, which is proportional to fc2^, whereas under variant evaluation, the 
maximum number of active choice points is only 2k. However, there are cases, 
such as occurs in the evaluation of rrtc(X,Y), where the initial call pattern is 
identical under either evaluation strategy. Here, the use of subsumption actually 
saves space as the representation of a consuming call on the choice point stack 
is more compact than that of a producer. Note that, even in the worst case, the 
choice point stack expansion is tied to the number of interdependent calls, and 
hence proportional to the table space. 

As discussed in Section 4.3, the DTSA engine uses more stack space than 
the TST due to the addition of specialized choice points for performing answer 
resolution from the DTSA. As the data in Table 5 shows, the TST engine out- 
performs the DTSA engine in terms of choice point space usage in all examples. 
Moreover, the overhead is significant, sometimes resulting in usage that is more 
than triple that of the TST engine. Finally, recall that the table space of the 
TST engine is proportional to that of the variant engine, and that its choice 
point space usage is proportional to its table space usage. Therefore, the TST 
engine’s total usage is proportional to that of the variant engine. 

6 Discussion 

We presented a new organization of tables based on time-stamped tries for sub- 
sumption based tabling. We showed from a theoretical as well as practical per- 
spective that it is superior to a tabling engine based on DTSA. Further we have 
shown that the space performance of such an implementation is no worse than 
a constant factor away from a variant implementation. 

Existence of an efficient subsumption based tabling engine opens up inter- 
esting new opportunities for expanding the applicability of top-down evaluation 
strategies. For instance, programs exist for which top-down, goal-directed query 
evaluations impose a high factor of overhead during the computation when com- 
pared to semi-naive bottom-up evaluation. Preliminary evidence suggests that 
the performance of our TST-based tabling engine augmented with , . 

_ is competitive with semi-naive bottom-up evaluation methods (see [5] for 
details). In general, abstraction of a call c is performed by first making a more 
general call, c', and allowing c to consume answers from c' . Observe that do- 
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ing call abstraction within a subsumptive engine on a call c amounts to losing 
goal directedness as far as the evaluation of c is concerned. Thus by selectively 
abstracting calls we can vary the degree of goal directness employed during an 
evaluation without changing the core evaluation strategy. 
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Abstract. This paper presents a logical framework for low-level ma- 
chine code and code generation. We first define a calculus, called sequen- 
tial sequent calculus, of intuitionistic propositional logic. A proof of the 
calculus only contains left rules and has a linear (non-branching) struc- 
ture, which reflects the properties of sequential machine code. We then 
establish a Curry-Howard isomorphism between this proof system and 
machine code based on the following observation. An ordinary machine 
instruction corresponds to a polymorphic proof transformer that extends 
a given proof with one inference step. A return instruction, which turns 
a sequence of instructions into a program, corresponds to a logical ax- 
iom (an initial proof tree). Sequential execution of code corresponds to 
transforming a proof to a smaller one by successively eliminating the last 
inference step. This logical correspondence enables us to present and an- 
alyze various low-level implementation processes of a functional language 
within the logical framework. For example, a code generation algorithm 
for the lambda calculus is extracted from a proof of the equivalence the- 
orem between the natural deduction and the sequential sequent calculus. 

1 Introduction 

Theoretical foundations of syntax and semantics of functional languages have 
been well established through extensive studies of typed lambda calculi. (See 
[14, G] for surveys in this area.) Unfortunately, however, those theoretical results 
are not directly applicable to implementation of a functional language on a 
low-level sequential machine because of the mismatch between models of typed 
lambda calculi and actual computer hardware. For example, consider a very 
simple program {Xx.Xy.{x,y)) 1 2. In the typed lambda calculus with products, 
this itself is a term and denotes an element in a domain of integer products. In 
an actual language implementation, however, this program is transformed to an 
intermediate expression and then compiled to a sequence of machine instructions. 
The details of the compiled code depend on the target computer architecture. 
Fig. 1 shows pseudo codes we consider in this paper for a stack-based machine 
and for a register based machine. The properties of these codes are radically 
different from those of existing semantic models of the lambda calculus. As a 
result, theoretical analysis of a programming language based on typed lambda 
calculi does not directly extend to implementation of a programming language. 
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Code(labell) 
Const (1) 
Const (2) 

Call (2) 
Return 

labell: Acc(O) 

Acc(l) 

Pair 

Return 



rO <- Code(labell) 

rl <- Const (1) 

r2 <- Const (2) 

rO <- call rO with (rl,r2) 

Return (rO) 

labell: r2 <- Pair(rl,rO) 

Return (r 2) 



In a stack-based machine. In a register-based machine. 

Fig. 1. Machine codes for {Xx.Xy.{x,y)) 1 2 



The general motivation of this study is to establish logical foundations for im- 
plementing a functional language on conventional computer hardware. To achieve 
this goal, we need to find a constructive logic appropriate for machine code, and 
to establish a logical interpretation of a compilation process from a high-level 
language to machine code, possibly using an intermediate language. In a previ- 
ous work [17], the author has shown that the process of translating the typed 
lambda calculus into an intermediate language called “A-normal forms” [4] is 
characterized as a proof transformation from the natural deduction proof sys- 
tem to a variant of Gentzen’s intuitionistic sequent calculus (Kleene’s G3a proof 
system [9]). However, A-normal forms are still high-level expressions, which must 
be compiled to machine code. A remaining technical challenge is to establish a 
logical framework for machine code and code generation. An attempt is made in 
the present paper to develop such a framework. 

We first define a proof system, called , , _ . , , , of intuition- 

istic propositional logic, whose proofs closely reflect the properties of low-level 
machine code. By applying the idea of Gurry-Howard isomorphism, the . y- 

(LAM for short) is derived from the calculus. When we regard 
the set of assumptions in a sequent as a list of formulas, then the derived ma- 
chine corresponds to a stack-based abstract machine similar to those used, for 
example, in Java [13] and Gamllight [12] implementation. We call this machine 
the stack-based logical abstract machine (SLAM). When we regard the set of 
assumptions as an association list of variables and formulas, then the derived ma- 
chine corresponds to a “register transfer language” which is used as an abstract 
description of machine code in a native code compiler. We call this machine the 
register-based logical abstract machine (RLAM) . 

We prove that the sequential sequent calculus is equivalent to existing proof 
systems of intuitionistic propositional logic. From the proofs of the equivalence, 
we can extract code generation algorithms. The choice of the source proof system 
determines the source language, and the choice of the representation of an as- 
sumption set determines the target machine code. For example, if we choose the 
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natural deduction as the source proof system and the association list representa- 
tion of an assumption set, then the extracted algorithm generates RLAM code 
for a register machine from a lambda term. Other combinations are equally pos- 
sible. This framework enables us to analyze compilation process and to represent 
various optimization methods within a logical framework. 

Backgrounds and related works. There have been a number of ap- 
proaches to systematic implementation of a functional programming language 
using an abstract machine. Notable results include Landin’s SECD machine [11], 
Turner’s SK-reduction machine [20], and the categorical abstract machine of 
Cousineauet et. al. [2]. In a general perspective, all those approaches are source 
of inspiration of this work. The new contribution of our approach is to provide 
a formal account for low-level machine code based on the principle of Curry- 
Howard isomorphism [3,7]. In [2], it is emphasized that the categorical abstract 
machine is a law-level machine manipulating a stack or registers. However, its 
stack based sequential machine is ad-hoc in the sense that it is outside the cate- 
gorical model on which it is based. In contrast, our LAM is directly derived from 
a logic that models sequential execution of primitive instructions using stack or 
registers, and therefore its sequential control structure is an essential part of 
our formal framework. We establish that a LAM program is isomorphic to a 
proof in our sequential sequent calculus, and that a code generation algorithm 
is isomorphic to a proof of a theorem stating that any formula provable in the 
natural deduction (or a sequent calculus) is also provable in the sequential se- 
quent calculus. This will enable us to extend various high-level logical analyses 
to low-level machine code and code generation process. 

With regard to this logical correspondence, the SK-reduction machine [20] 
deserves special comments. The core of this approach is the translation from the 
lambda calculus to the combinatory logic [3]. As observed in [3,10], in the typed 
setting, this translation algorithm corresponds exactly to a proof of a well know 
theorem in propositional logic stating that any formula provable in the natural 
deduction is also probable in the Hilbert system. The bracket abstraction used 
in the translation algorithm (to simulate lambda abstraction in the combinatory 
logic) is isomorphic to a proof of the deduction theorem in Hilbert system stating 
that if Ti is provable from Z\ U T 2 then T 2 DT 1 is provable from A. Although this 
connection does not appear to be well appreciated in literature, this can be 
regarded as the first example of Curry-Howard isomorphism for compilation of a 
functional language to an abstract machine. However, the SK-reduction machine 
is based on the notion of functions (primitive combinators) and does not directly 
model computer hardware. We achieve the same rigorous logical correspondence 
for machine code and code generation. 

Another inspiration of our work comes from recent active researches on defin- 
ing a type system for low-level machine languages. Morrisett et. al. [16,15] define 
a “typed assembly language.” Stata and Abadi [19] define a type system for Java 
byte-code. In those works, a type system is successfully used to prove soundness 
of code execution. However, the type system is defined by considering each in- 
struction’s effect on the state of memory (registers or stack), and its logical 
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foundations have not been investigated. In our approach, the logical abstract 
machine is derived from a logic. This enables us to present various implementa- 
tion processes such as code generation entirely within a logical framework. 

Paper Organization. Section 2 analyzes the nature of machine code and 
defines the sequential sequent calculus. Section 3 extracts the logical abstract 
machine from the proof system of the sequential sequent calculus and establish 
a Curry-Howard isomorphism between the calculus and the machine. Section 4 
shows that the sequential sequent calculus is equivalent to other formalisms for 
intuitionistic propositional logic, and extracts compilation algorithms. Section 5 
discusses some issues in implementation of a functional language. 

Limitations of space make it difficult to present the framework fully; the 
author intends to present a more detailed description in another paper. 

2 The Sequential Sequent Calculus 

The first step in establishing logical foundations for machine code and code 
generation is to find a constructive logic that reflects the essential natures of 
conventional sequential machines. 

By examining machine code such as those shown in Fig. 1, we observe the 
following general properties. 

1. Machine code is constructed by sequential composition of instructions, each 
of which performs an action on machine memory. The machine is run by 
mechanically executing the first instruction of the code. 

2. An instruction is polymorphic in the sense that it may be a part of various 
different programs computing difference values. The result of the entire code 
is determined by a special instruction that returns a value to the caller. 

3. To represent arbitrary computation, the machine supports an operation to 
call a pre-compiled code. 

In the following discussion, we write Al> t for a logical sequent with a set A of 
assumptions and a conclusion r. 

Logical inference rules that reflect item 1 are those of the form 

A2 [> T 
Al !> T 

which have only one premise and do not change the conclusion r. By interpret- 
ing an assumption set as a description of the state of machine memory, a proof 
composed by this form of rules would yields a sequence of primitive instructions, 
each of which operates on machine memory. This is in contrast with the natu- 
ral deduction where rules combine arbitrary large proofs. Moreover, sequential 
execution of machine is modeled by the (trivial) transformation of a proof to a 
smaller one by successively eliminating the last inference step. 

In the context of proof system, the item 2 is understood as the property 
that each instruction corresponds not to a complete proof but to an inference 
step that extends a proof. This observation leads us to interpret each machine 
instruction / as a polymorphic function that transforms a proof of the form 
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Ai\> T 



to a proof of the form 



Ai\> T 
A2\> T 



Ri 



for , T. At run-time, the instruction corresponding to this 

rule transforms the memory state represented by A 2 to the one represented 
by Z\i. Note that the direction in which machine performs the memory state 
transformation is the opposite to the direction in logical inference. For example, 
an instruction that creates a pair of integer is modeled by the following inference 
step. 



A; tiAt2 O t 



(pair) 



A return instruction in a program computing a value of type r corresponds to 
an axiom Z\ O r such that t G A. 

The logical interpretation of item 3 of the ability to call a pre-compiled code 
is the availability of a proof of a sequent, and it can be modeled by a rule to 
assume an already proved formula as an axiom. 

The above analysis leads us to define the sequential sequent calculus of in- 
tuitionistic propositional logic. We first consider the calculus for stack-based 
machines where an assumption set is a list of formulas. 

We write (ti; . . . ; r„) for the list containing ti, . . . , r„, and write A; r for the 
list obtained from A by appending r to A. We also use the notation A{n) for 
the element in the list A (counting from the left starting with 0,) and |Z\| for 
the length of A. The empty list is denoted by 4>. A list of assumptions describes 
the type of a stack. We adopt the convention that the right-most formula in a 
list corresponds to the top of the stack. We assume that there is a given set of 
non- logical axioms (ranged over by 6), and consider the following set of formulas 
(ranged over by r). 

r ::= b \ rAr | rVr | {A => t) 

tiAt 2 and riVr 2 are conjunction and disjunction, corresponding to product and 
disjoint union, respectively. A formula (A r) intuitively denotes the fact that 
r is derived from A. Its constructive interpretation is the availability of a proof of 
the sequent A\>t. This serves as an alternative to implication formula. The set 
of proof rules is given in Fig. 2. The rationale behind the rather unusual names 
of the rules will become clear later when we show a correspondence between this 
logic and an abstract machine. We write S$ for this proof system, and write 
iSs F Z\ > r if Z\ > r is provable in this proof system. 

The sequential sequent calculus suitable for register-based machines is ob- 
tained by changing the representation of an assumption list Z\ to a named as- 
sumption set. We let T range over functions representing named assumption 
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The axiom: 
(return) A; r > r 
Inference rules. 

Z\ ; ri > r 



(acc) 

(pair) 

(snd) 

(inr) 

(code) 

(app) 



T 

A’, tiAt 2 > r 
A- n; T2 > r 

A; T2 > r 
A; riAr2 > r 

A; nVr2 > r 
A; T2 > r 

A; (Aq tq) > r 



(ri G A) (const) 
(fst) 

(ini) 

(case) 



A; 6 > r 
A > T 

A; n > T 
A; riAT2 > r 

A; TiVr2 > r 
A; n > T 

A; T3 > T 



(if 6 is a non-logical axiom) 



A > r 
A; (Ai To) > T 



A; tiVt 2 > T 
(if Ao > To) (call) 



(if h A; Ti > T3 and h A; T2 > T3) 
A; To > T 



A; (Ao To); Ao > T 



A; (Ao; Ai => to); Ao > t 

Fig. 2. 5s: the Sequential Sequent Calculus for Stack Machines 



sets, and write F,x : t for the function F' such that dom{F') = dom{F) U {a:}, 
F'{x) = T, and F'{y) = F{y) for any y € dom{F),y ^ x. The set of proof rules 
is given in Fig. 3. We write Sr for this proof system, and write Sr h F O t if 
F > T is provable in this proof system. 



3 The Logical Abstract Machines 

Guided by the notion of Curry-Howard isomorphism [3,7], machine instructions 
are extracted from the sequential sequent calculi. 



3.1 SLAM: The Stack Based LAM 

The stack-based logical abstract machine, SLAM, is obtained from the calculus 
Ss- The set of instructions (ranged over by I) is given as follows 

/ ::= Return | Acc(n) | Const(c^) | Pair | Fst | Snd 
I Ini I Inr | Case | Code(C') | Call(n) | App(n) 

where C ranges over lists of instructions. We adopt the convention that the left- 
most instruction of C is the first one to execute, and write /; C (and C"; C) for 
the list obtained by appending an instruction / (a list C' of instructions) at the 
front of C. The type system of these instruction is obtained by decorating each 
rule of Ss with the corresponding instruction. Fig. 4 shows the typing rule for 
SLAM, which is the term calculus of Ss- 
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The axiom: 

(return) F,x ■. t \> t 
Inference rules. 

r, a: : n, 1 / : n > r 



(acc) 

(pair) 

(snd) 

(inr) 



r,x : Tl \> T 



r X \ h ^ T 

(const) — ’ (if 6 is a non-logical axiom) 



r,x : Ti,y : T2, z : tiAt2 > T 
r,x ■. Ti,y : T2 > T 

r, X : TlAT 2 ,y ■ T 2 > T 

r, X : tiAt 2 t> T 

r,x : T 2 ,y ■■ tiWt 2 > r 

r,X : T 2 \> T 



(ini) 



r,x :TiAT2,y \Ti:> T 
r,x ■.riAT2t>r 

r,x : Ti,y : riVra > r 
r, X ■. T1 \> T 



, , r,® : TiVr 2 ,i/ : T 3 > r ^ n ^ 

(case) = (if r, zi : n [> T 3 , T, 22 : T 2 > T 3 ) 

r,x \ t\\!t 2 > r ^ 

, , r, a; : (To =i> ro) > r /.. , n ^ \ 

(code) ^ ^ (if h To > ro) 



(call) 



(app) 



A, a; : (A 7-3),^ : tq > r 
A, a; : (A tq) > r 

(A = {l/i : n; • • • ; 1/n : t„}, A(aii) = Ti, 1 < i < ?i) 
A, a; : (A, A =» 7-3);^ : (A => tq) > r 
A, a: : (A, A tq) > r 

(A = {t/i ■■ Ti; ■ ■ ■ ■, yn : r„}, A(aii) = Ti, 1 < » < ?^) 



Fig. 3. Sr: the Sequential Sequent Calculus for Register Machines 



Each instruction “pops” arguments (if any) from the top of the stack and 
pushes the result on top of the stack. Code(C) pushes a pointer to code C. 
Call(n) pops n arguments and a function, calls the function with the arguments, 
and pushes the result. App(n) pops n arguments and a function closure and 
pushes the function closure obtained by extending the closure’s stack with the n 
arguments. The meanings of the other instructions are obvious from their typing 
rules. Their precise behavior is defined by an operational semantics, given below. 
The set of run-time values (ranged over by v) is defined as follows 

V ::= I (u, u) | inl{v) \ inr{v) \ cls{S,C) 

where cls{S, C) is a function closure consisting of stack S, which is a list of 
values, and code C. The operational semantics is defined as a set of rules to 
transform a configuration 

(S,C,D) 

where A is a “dump,” which is a list of pairs of S and C. Fig. 5 gives the set 
of transformation rules. The reflexive, transitive closure of the relation — > is 
denoted by — >. 
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(return) A; r > Return : r (acc) r 



A> Acc(n);C : r ' 

, , A\bt> C : T / • N L\; riAr2 > C ; r 

^ A > Const(c"); C : t A;n;r2 > Pair;C : r 

('ft'l L\; n > C : r , . A;t2>C : t 

A; tiAt2 > Fst; C : t ™ A; tiAt 2 > Snd; C : r 

, A;riVr2>C : r A;tiVt2>C' : r 

^ ' A; Ti > Ini; C : t ^ A;t 2 t> Inr; C : r 

(case) —7 — ^ (if h A; n > Ci : T3 and h A; T2 > C2 : T3) 

' ' A; tiVt 2 > Case((7i,(72); C : r ' 

3;(3i ^ n,);3i C>Call(n);C : T 

r ^ To) > C : r ri a i _ ^ 

(aPP) zi;(^2;Ai^ro);A2>App(n);C' : r - n) 

Fig. 4. Type System of SLAM 




(S'; n, Return, (f>) 
(S; u, Return, D; (So, Co)) 
(S, Acc(n);C,D) 
(S, Const(c);C,D) 
(S;ni;u2,Pair;C, D) 
(S; (ni,n2),Fst;C,D) 
(S; (wi,t;2),Snd;C,D) 
(S;n, lnl;C,D) 
(S;n, lnr;C,D) 
(S;mZ(n),Case(Ci,C2);C,D) 
(S; inr{v), Case(Ci,C2); C, D) 
(S, Code(Co);C,D) 
(S; cls{So, Co); wi; • • • ; Wm, Call(m); C, D) 
{S;cls{So, Co); wi; • • • ; Wm, App(m); C, D) 



(v,4),<l)) 

(So;n,Co,C) 

{S-,S{n),C,D) 

{S;c,C,D) 

(S; (ni,t;2),C,D) 

(S;ni,C,D) 

(S;u2,C,D) 

{S;inl{v),C,D) 

{S;inr{v),C,D) 

{S-,v,Ci,D- (S,C)) 
(S;n,C2,f?;(S,C)) 
(S;ds(<?(>,Co),C, O) 

(So; ui; • • • ; Um, Co, -D; (S, C)) 

(S; ds{So; wi; • • • ; Wm, Co), C, D) 



Fig. 5. Operational Semantics of SLAM 
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Evaluation of code under this operational semantics corresponds to the triv- 
ial proof transformation by successively eliminating the last inference step. To 
formally establish this relation, we define the typing relations for values and for 
stack (written \= v : t and |= S' : Z\ respectively) as follows. 

• \= -.b. 

• ^ (vi, U2) : TiAr2 if 1 = : ti and |= V2 '■ T2- 

• 1= inl{v) : tiVt 2 \i\= v \ t\ 

• 1 = inr{v) : tiVt 2 if |= w : T2. 

• \= cls{S, C) \ {A ^ t) a \= S \ Ai and Ai\ A\> C \ t for some Ai. 

• 1 = S : Z\ if S = (wi; . . . ; u„), A = (ti; ; Tn) such that \= Vi \ Ti{l < i < n) . 

We can then show the following. 

Theorem 1. , 



A2 l> C2 : T 



A\ O Ci; C2 '■ T 

Sih^l - (Si,Ci;C 2 ,i^) ^ (S 2 ,C 2 ,i^) - S 2 h ^2 

, This is shown by induction on the number of reduction steps of the ma- 
chine. The proof proceeds by cases in terms of the first instruction of C . For 
the instructions other than Case(C'i,C'2) and Call(n), the property is show by 
checking the rule of the instruction against the proof rule and then applying the 
induction hypothesis. The cases for Case(C'i,C'2) and Call(n) can be shown by 
using the fact that the only instruction that decreases (pops) the dump D is 
Return. □ 

We can also show that the machine does not halt unexpectedly. To show this 
property, we need to define the type correctness of a dump. We write \= D \ t to 
represent the property that D is a type correct dump expecting a return value 
of type T. This relation is given below. 

• h : 'T- 

• 1 = D ; (S', C) : r if there are some A and r' such that S \= A, A]t [> C : t' 
and \= D \ t' . 

Theorem 2 . , At>C : t S A . D ■. t .. (S,C,D) — > (S', C", D') 

_ C A',t' , . ... S' A' A' t> C ■. t' . 

h £»' : t' 

, By cases in terms of the first instruction of C. 

Combining the two theorems, we have the following. 
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Corollary 1. , A > C : t 5 h ^ (S,C,4>) ^ {S',C',D) _ . 

{S",C'\D') {S\C',D) {S",C",D') .. {S',C',D) = {v,4>A) 

... . \= V T 

, By the property of the proof system, there are A\ Co such tha C = 
Co; Return and Z\';r O Return : r. It is easily checked that if D ^ (jj then 
C ^ 4>- Then by Theorem 2, the property that {S^C,4>) (S',C',D) and 

there is no {S" ,C" , D') such that (S\C',D) — > {S" ,C" , D') implies that 
(S', Co; Return, (/)) (Si, Return, <()) for some Si. By Theorem 1, ^ Si : A';t. 
Thus Si = S[]v such that \= v \ t. Then (S(; u, Return, 4>) — > (u, </>, 4>). □ 



3.2 RLAM: The Register-Based LAM 

Parallel to the stack-based logical abstract machine, SLAM, we can also con- 
struct the register based machine, RLAM, from the sequential sequent calculus, 
Sr, and we can show the properties analogous to those of SLAM. Here we only 
give the set of instructions and the typing rules in Fig. 6, where cc<— / intuitively 
means that the value denoted by / is assigned to register x. The intuitive mean- 
ing of each instruction can then be understood analogously to the corresponding 
instruction of SLAM. 



4 Code Generation as Proof Transformation 

The sequential sequent calculus is shown to be equivalent to existing intuition- 
istic propositional calculi with conjunction and disjunction. Moreover, the proof 
of the equivalence is effective. For example, any proof in the natural deduction 
of intuitionistic propositional logic can be transformed to a proof in the sequen- 
tial sequent calculus, and vice versa. The same also holds for the intuitionistic 
propositional sequent calculus. Through Curry-Howard isomorphism, these re- 
sults immediately yield compilation algorithms from the lambda calculus or the 
A-normal forms to the logical abstract machine. 

Here we only consider the typed lambda calculus (with products and sums.) 
The set of types is given by the following grammar. 

r ::= b \ tDt \ tAt \ rVr 

The set of typing rules of the lambda calculus is given in Fig. 7. We denote this 
proof system by Af and write M \~ F X> M ■. t if F X> M :ris provable in this 
proof system. 

We identify implication type tiDt 2 of N with code type ((ti) ^ T 2 ) of Ss- 
For a type assignment T in A/" we let Ap he the corresponding assumption list 
in Ss obtained by a linear ordering on variables, i.e., if F = {x\ \ t\, . . . ,Xn '■ t„} 
such that Xi < xj for any 1 < i < j < n, then Ar = {ti; ; Tn). If a; € dom{F) 
then we write lookup{F,x) for the position in corresponding to x. 
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;:= Return(x) | x^y | a:<— Const(c*’) | x-^Pa\r(y,z) \ a:<— Fst(j/) | a:^Snd(j/) 
I a:<— Inl(y) | x<— Inr(y) | *<— Case(j/,(a;).C'i,(a:).C'2) | *<— Code(C) 

I y^Call X with {y\^xi, , y„^Xn) 

I y^App x to {yi^xi, ..., y„^Xn) 



(return) F,x '.t\> Return(a;) : r 



(const) 



, r,x-.Ti-y.Ti^C : T 
' r,x:ri> y^x;C : r 

r,x \ Tl\y \ T2\Z ■. Tlf\T2 \> C : T 



r,x : bt> C : T r,x ■. Ti\y : T2; z : tiAt2 > C : r 

r > a:<— c*’; C : r r,x : Ti;y : T2 > z^Pa\r{x,y);C : t 

r,x : TiAT2-,y : n > C : r , , F,x : TiAT2',y : T2 \> C : t 

F,x : tiAt 2 > y^Pst{x);C : r ^ i"', a: : tiAt 2 > t/^Snd(a;); C ; r 

F,x : Ti;y : tiVt2 > C : t .. , F,x \ T2\y ’. riVr2 > (7 : r 

-T, a; ; ri > j/^lnl(a;); C : t ' F,x : T2 t> y^lnr(a;); C : r 

r, X : Ti Vt 2; {/ : T3 > C : r 

F,x : tiVt 2 > j/^Case(a;, (21). Ci, (22) C'2);C : r 
(if r, 2i : Ti > Cl : T 3 , r, 22 : T2 > C2 : T3 ) 

r, a; ; (Co ro) > C : r ^ n ^ _ i 

r a ^ (it h 1 0 > C . tq) 

r > a;^Code(C )-,C:t 

Fi,x : {F2 ^ Tp);y : tq t> C : t 

Fi,x : (F2 ^ To) > y^Call x with (yi^xi, ..., yn^Xn); C : t 
{F 2 = {yi : n; • • • ; i/n ; Tn}, Fi{xi) = Ti,l < i < n) 

Fi,x : {F2 ,Fo => To)\y : (A => rp) > C : r 

Fi,x : {F2,F3 => To) > y^AppI x to {yi^xi, ..., yn^Xn)\ C : r 
{F2 = {yi : n; • • • ; t/n : r^}, F\{xi) = Ti,l <i <n) 

Fig. 6. The Register-Based Logical Abstract Machine, RLAM 



(if h To > C' : ro) 



(taut) F,x:Tt>x : t (axiom) F \> : t (T>:I) 



F, X : Ti t> M : n 
F t> Xx.M : tiDt2 



F > Ml : tiDt2 F > M2 : ri 
F t> Ml M2 '. T2 



F > Ml : Ti F t> M2 : T2 



F\>{Mi,M2) : tiAt2 



(A;E1) 



F t> M : tiAt2 
F > M.l : Ti 



(A;E2) 



F t> M : tiAt2 
F > M .2 : T2 



F t> M : Ti ('VI 2 ') rt>M : T2 

F t> inl[M) : riVr2 ’ F t> inr(M) : ti\/t2 

F > Ml : ti\/t2 F,x:tiP> M2 ’.to F,y : T2 l> M3 : T3 
F > case Mi of a:. M2, y. M3 : T3 



Fig. 7. A/”: Typed Lambda Calculus with Products and Sums 
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We first show that any lambda term M can be translated to SLAM code 
|M] that extends a given stack with the value denoted by M. To establish this 
connection, we define the following relation for SLAM code. 

C : Ai ^ A2 for any C , r if 5s h Z\2 O C" : r then 5s b Z\i > C; C : r. 



From this definition, it is immediate that each inference rule of SLAM of the 
Z\2 > C : r 



this relation is “transitive”, i.e., if C\ : Z\i 



is regarded as the relation I ■. Ai ^ A2, and that 
Z\2 and C2 ■ A2 ^ A3 then 



Ci; C2 ■ Ai ^ A3. 

The following lemma plays a central role in establishing the logical corre- 
spondence. Since a proof of this lemma gives a code generation algorithm and 
its type correctness proof, we show it in some detail. 



Lemma 1 . , Af F \> M : t .. .. . . |M] , .... |M] : 

Ap => Ap; T 



, By induction on M . 

Case X. Since x : t G F,hy rule (acc), Acc{lookup{F, x)) : Ap Ap;r. 

Case c^. By rule (const), Push(c^) : Ap Ap; b. 

Case Xx.M'. By the typing rule, there are some ti,T 2 such that r = T1DT2, 
and Af \- F,x : Ti [> M' : T2- By the induction hypothesis, |M'] : Ap^x-.r^ 
Ap^x-ti;t2- Since Ss b Ap^x-.ti;t 2 t> Return : T2, by definition, Ss b Ap^x-.ri > 
|M']; Return : T2- By the bound variable convention in Af we can assume that x 
is larger than any variables in dom{r) and therefore Ap^x-.ri = Ap;ri. Thus we 
have Code(|M'];Return) : Ap Ap; {Ap; n T2). Let n = \Ap\. By repeated 
applications of rule (acc), 

Code(|M'];Return);Acc(0);- • -;Acc(n — 1) : Ap ^ Ap; {Ap; n T2); Ap 
By rule (app), we have 

Code(|M'];Return));Acc(0);- • -;Acc(n — l);App(n) : Ap Ap; ((ri) T2) 



Case Ml M2- By the type system of Af, there is some t\ such that N b 
r \> Ml : tiDt and Af \~ F \> M2 : n. By the induction hypothesis for Mi, 
|Mi] : Ap Ap; ((n) r). Let x be a variable larger than any variables in 

dom{F). By the property of Af, Af b T, x : riDr O M2 : n. By the choice of 
X, Apx:({t,)^t) = Ap; ((n) t). Then by the induction hypothesis for M2, 

IM2] : Ap; ((n) ^ r) ^ Ap; ((n) ^ r); n Then we have 

[Mil;|M2l;Call(l): Z\r=^Ar;r 

Case (Ml, M2). By the type system of Af, there are some ti,T 2 such that 
r = TiAr2, Af \- Fo Mi : n and Af \~ Fo M2 ■ T2. By the induction hypothesis 
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for Ml, |Mi] : Ar Ar;ri. Let a: be a variable larger than any variables in 
dom{r). By the property of N, N \- F,x \ \> M2 : T2. By the choice of x, 

Ar,x-.Ti = Ar;ri. Then by the induction hypothesis for M2, I-M2] : Ar',Ti 
Ar',Ti,T2 Thus we have 

|Mi];|M2];Pair : Ap =A A^■,Tl^T2 



Case M.l. By the type system of N, there is some ti such that N \~ F\> M\ : 
tAti. By the induction hypothesis, \Mi\ : Ap => Ap;tAti. Thus we have 
|Mi];Fst : Ap ^ Ap-,r 

The case for M .2 is similar. 

Case inl{Mi). By the type system of Af, there are some n, T2 such that r = 
riVr2 and Af h T > M\ : n. By the induction hypothesis, |Mi] : Ap => Ap; t\. 
Then we have |Mi];lnl : Ap Ap;ti\/t2 
The case for inr{M) is similar. 

Case Ml , x. M2, y. M3. There are some ti, T2 such that Mi : tiVt2, 
F,x : Ti O M2 : r, and F,y : T2 \> M3 : r. By the induction hypothesis for 
^ii I-^^l : => Ap;ti\/t2- By the bound variable convention in the lambda 

calculus, we can assume that x, y are larger than any variables in dom(F). Thus 
^r,x:ri = Ap-,Ti and Ap^y,x2 = Ap;t2- Then by the induction hypotheses for 
M2 and M3, IM2] : Ap;ri ^ Ap; ti; t and IM3] : Ap; T2 Ap; T2; r Then by 
definition Ss b Ap;ri O |M2];Return : r and Ss b Ap;T2 \> IMsJiReturn : r, 
and therefore 



|Mi];Case(|M2];Return,|M3];Return) : Ap => Ap; r 



□ 



Theorem 3 . , Af \~ F \> M : t .. .. - y Cm 

.. . Ss b Ap o Cm '■ T 

, By Lemma 1 , there is some |M] such that |M] : Ap ^ Ap; r. Take Cm 
to be |M];Return. Since Ss b Ap;r > Return : r, we have Ss b Ap O Cm ■ t. 

□ 

Those who have written a byte-code compiler would immediately recognize 
the similarity between this proof and a compilation algorithm; but they would 
also recognize some redundancy this translation produces. This point will be 
taken up in Section 5 when we discuss implementation issues. 

The sequential sequent calculus is sound with respect to the intuitionistic 
propositional logic, and any sequent provable in the sequential sequent calculus 
is also provable in other proof systems including the natural deduction and a 
sequent calculus. Under our Curry-Howard isomorphism, this means that the 
above theorem is reversible. To formally state this connection, we define the 



The Logical Abstract Machine 313 



type T oi N corresponding to a type t of Ss as follows. 

b=b 

((ti; . . . ; r„) ^ r) = t[D ■ ■ ■ 
tiAt2 = tTAt^ 
tiVt2 = tTVt^ 



Let A be an assumption set of Ss and let n = |Z\|. We write Fa for th e type 
assignment of Af such that dom{r) = {x\, . . . ,x„} and F^ixi) = A{i), where 
x\,...,Xn are distinct variables chosen in some arbitrary but fix way (we can 
use integer i itself for Xi.) We can then show the following. 

Theorem 4., , S$ A \> C \ t .. .. - . . Me .... 

Af h Fa I> Mq ■ f 

, By induction on the derivation of h Z\ > C : t using the substitution 
lemma in the lambda calculus. □ 

Different from the relationship between the lambda calculus (natural deduction) 
and the combinatory logic (Hilbert system), the term obtained by a proof of this 
theorem is not a trivial one, but reflects the logical structure of the program 
realized by the code. This has the important implication of opening up the 
possibility of high-level code analysis. This topic is outside the scope of the 
current paper. In near future, we shall report on this topic elsewhere. 

The above two theorems are proved for the natural deduction. The same 
results can be proved for Kleene’s G3a, yielding translation algorithms between 
A-normal forms and LAM code. 



5 Implementing a Functional Language Using LAM 

In this section, we consider some issues in implementing a functional language 
based on a logical framework presented in this paper. 

A typical implementation of a functional language consists of the following 
steps. 

1. A-norm transformation. 

2. Lambda lifting and closure optimization. 

3. Pseudo code generation. 

4. Register allocation and native code generation. 

These processes are usually thought of as those required for converting a heigh- 
level programming language into a low-level machine language. A machine lan- 
guage is indeed low-level for the programmer in the sense that it consists of simple 
and primitive operations. However, this does not means that code generation and 
optimization are inevitably “low-level” and ad-hoc. As we have demonstrated, a 
machine language is understood as a proof system, and code generation process 
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is a proof transformation. These results enables us to analyze various implemen- 
tation issues in a rigorous logical framework. 

In a logical perspective, A-normal transformation is to transform the elim- 
ination rules in the natural deduction system to combinations of left rules and 
cut rules in a sequent calculus. The resulting sequent calculus (Kleene’s G3a) 
is much closer to the sequential sequent calculus, and therefore the subsequent 
code generation process become much simpler. This topic is outside the scope 
of the present paper. The interested reader is referred to [17] for Curry-Howard 
isomorphism for A-normal translation. In the rest of this section, we consider 
some issues in the context of direct-style compilation for the lambda calculus. 

5.1 Lambda Lifting and Closure Optimization 

Lambda lifting and associated closure optimization are the processes of absorb- 
ing the difference between functions and machine code. (See [18,1] for the de- 
tails.) In the lambda calculus, one-argument function abstraction and function 
application are the primitives. On the other hand, in computer hardware, the 
unit of execution is a pre-compiled code requiring multiple arguments. Our log- 
ical abstract machine properly reflects this situation, and is therefore a suitable 
formalism to analyze the efficiency of these processes. 

Examining the code generation algorithm given in the proof of theorem 3 re- 
veals the redundancy in treating nested lambda abstractions and nested lambda 
applications. For example, consider the lambda term {Xx.Xy.{x,y)) 1 2. 
A straightforward application of the algorithm yields the following code in SLAM 
(written in a linear fashion using labels). 

Code(labell) ;Const(l) ;Call(l) ;Const(2) ;Call(l) ;Return 
labell : Code(label2) ;Acc(0) ;App(l) ;Return 

label2: Acc(O) ;Acc(l) ; Pair; Return 

Apparently, the intermediate closure creation is redundant. One way of elimi- 
nating this redundancy is to translate the lambda calculus to an intermediate 
language that is closer to the logical abstract machine. We show one possible 
definition of an intermediate language below. 

P ::= decl D in M 
D ::= 4> I D; L = X{xi, . . . , Xn)-M 
M ::=x\ L \ (MM ••• M) | (M,M) | M.l | M.2 
I inl{M) I inr{M) \ Mi Ax. M 2 , Ax. M 3 

In this definition, a program P consists of a sequence of declarations D and a 
program body. A declaration is an association list of a label (denoted by L) and 
a multi-argument function A(xi, . . . ,Xn)-M such that FV{M) = {xi, . . . ,x„}, 
and corresponds to a “super combinator” which is a target expression of lambda 
lifting [18]. Instead of lambda abstraction and lambda application, the set of 
terms contains a label L referring to a code, and a function call with multiple 
arguments. 
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A type system for this language and a compilation algorithm from this lan- 
guage to the logical abstract machine are easily given. However, a non-trivial 
static analysis is needed to translate the lambda calculus to this language. This 
is outside the scope of the present paper. We plan to present a detailed account 
for the type-directed translation from the lambda calculus to LAM code using 
this intermediate language elsewhere. Here we only show an example of the com- 
pilation process using this intermediate language. Fig. 8 is an actual output of 
a prototype compiler the author has implemented based on the logical approach 
presented in this paper. In this example, $1 is a label and [$1 1 2] is function 
application to multiple arguments. One can see that the generated code does not 
contain the redundancy mentioned above. Also note that the compiler calculates 
the maximum height of the stack needed for each code. 



Source expr : 

(fn x=>fn y=>(x,y)) 1 2 

Typecheked and transformed to: 
decls 

$1 = (fn <x,y> => (x,y)) : ( ’ a. ’b. < ’a; ’b> => ’a * ’b) 
in 

[|$ 1 | 1 2 ] 
end 

: int * int 

Compiled to SLAM code: 

Start at :labelO 

Max stack size : 3 
labelO: Code(labell) 

Const (1) 

Const (2) 

App(2) 

Return 

Fig. 8. Compilation process for {Xx.Xy.{x,y)) 1 2 



Max stack size : 4 
labell: Acc(O) 
Acc(l) 

Pair 

Return 



5.2 Generating Efficient RLAM Code 

We have explained our logic-based approach using the stack-based machine 
SLAM, which is suitable for a byte-code interpreter. However, some inefficiency 
is inevitable in a stack-based code mainly because its restricted memory access 
through the stack-top pointer. For example, accessing and pushing two argu- 
ments Acc(O) and Acc(l) in the code shown in Fig. 8 for (x, y) is redundant if 
arguments can be passed through registers. By choosing a register-based ma- 
chine RLAM we defined in Section 3.2 we can solve this problem. As already 
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mentioned, all the major results so far presented hold for RLAM. Our proto- 
type compiler also generate RLAM machine code. Fig. 9 shows the RLAM code 
generated for {Xx.Xy.{x,y)) 1 2. 



Compiled to RLAM code : 

Start at : labelO 

labelO: rO <- Code(labell) labell: r5<- Pair(r3,r4) 

rl <- Const (1) Return(r5) 

r2 <- Const (2) 

rO <- Call rO with (r3<-rl, r4<-r2) 

Return (rO) 

Fig. 9. RLAM code for (Xx.Xy.{x,y)) 1 2 



In RLAM, an assumption list F in each sequent F\>C : r is a mapping from 
variable names to formula, and models the registers used at the time when the 
first instruction of C is executed. By this interpretation, RLAM is regarded as 

Aa O C : T 

a register transfer language where an inference step of the form -p 

indicates that the instruction I modifies the set of registers indicated by Fi to 
those of Ja. In particular, if /a extends Fi then I “loads” an empty register with 
a value. Note that the notation F,x : t may override x in F. This corresponds 
to re-using a register which is no longer “live,” i.e. if a; is not free in the premise. 

By the above simple analysis, it is expected that RLAM can serve as a 
formal basis to analyze and design register allocation. Katsumata’s recent result 
[8] indicates that this is indeed the case; he have shown that by incorporating 
the mechanism of linear logic, a calculus similar to RLAM is used to perform 
precise analysis on register liveness. 



6 Conclusions and Further Investigations 

We have developed a logical framework for machine code and code generation. 

As a logic for machine code, we have define the , , _ , 

which is a variant of a sequent calculus whose proof only involves left rules and 
has a linear (non-branching) structure. We have established a Curry-Howard 
isomorphism between this proof system and a sequential machine language. We 
have then shown that code generation algorithm is extracted from a proof of the 
equivalence theorem between the natural deduction and the sequential sequent 
calculus. We have also demonstrated that various implementation issues can be 
analyzed and expressed in our logical framework. 

This is a first step towards a logical approach to implementation of a high- 
level programming language, and there are a number of interesting issues remain 
to be investigated. Here we briefly mention some of them. 
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• Various language extensions. 

In order to apply the framework presented in this paper to actual language 
implementation, we need to extend it with various features of practical pro- 
gramming languages. Adding recursion is relatively straightforward (though 
the resulting proof system no longer corresponds to the intuitionistic propo- 
sitional logic.) A more challenging issue would be to extend the framework 
to classical logic for representing various control structures such as those 
investigated in [-5]. Another interesting issue in this direction is to consider 
higher-order logic to represent polymorphism. 

• Static analysis of machine code. 

As we have mentioned, we are developing a method to reconstruct the logi- 
cal structure of a program from machine code. Other possibility would be to 
develop a framework for type inference and abstract interpretation for ma- 
chine code. These static analyses would be particularly important in ensuring 
security in mobile and network programming. 

• Development of a practical compiler. 

Another important topic is to consider proof reduction and equational theory 
for machine code. They will provide a firm basis for code optimization. 

We believe that with further research for optimizations, the logical framework 
presented in this paper will serve as a basis for efficient and robust implementa- 
tion of high-level programming languages. 
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Abstract. Higher-order lazy narrowing is a general method for solving 
E-unification problems in theories presented as sets of rewrite rules. In 
this paper we study the possibility of improving the search for normalized 
solutions of a higher-order lazy narrowing calculus LN. We introduce a 
new calculus, LNfj, obtained by extending LN and dehne an equation 
selection strategy Sn such that LNg with strategy Sn is complete. The 
main advantages of using LNg with strategy Sn instead of LN include 
the possibility of restricting the application of outermost narrowing at 
variable position, and the computation of more specific solutions because 
of additional inference rules for solving flex-flex equations. We also show 
that for orthogonal pattern rewrite systems we can adopt an eager vari- 
able elimination strategy that makes the calculus LNfj with strategy Sn 
even more deterministic. 



1 Introduction 

Lazy narrowing is a method for solving E-unification problems in equational 
theories represented as sets of rewrite rules. It has been shown [2] that the lazy 
narrowing calculus forms a basis of functional logic programming. In recent years, 
various extensions of the lazy narrowing calculus to higher order equational 
theories have been proposed [3,4,14] in an attempt to define a suitable model 
for the design of an equational programming language. One such calculus is the 
calculus HLNC (Higher-order Lazy Narrowing Calculus) proposed by Suzuki, 
Nakagawa and Ida [14]. HLNC is based on the idea of combining the /3-reduction 
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of the lambda calculus and the first-order narrowing calculus LNC [6]. Based 
on HLNC, a programming system called CFLP (Constraint Functional Logic 
Programming) has been designed and implemented [5]. Independently, Prehofer 
studied higher-order lazy narrowing based on the higher-order rewrite system of 
Nipkow [9] and introduced the calculus LN [1 1] . 

Both calculi HLNC and LN are highly nondeterministic and they create a 
huge search space for solutions. In order to guarantee completeness, we must 
take into account all possible choices of (1) the equation in the current goal to 
be solved, (2) the inference rule of the calculus to be applied, and (3) the rewrite 
rule to be considered for outermost narrowing. For first-order lazy narrowing, 
research in reducing this non-determinism has brought important results [6,7,1] 
and gives an insight to how to eliminate some sources of the non-determinism 
in higher-order lazy narrowing. 

In this paper we tackle the problem of reducing the non-determinism of 
computing substitutions that subsume all the normalized solutions of a given 
higher-order goal. Our main contribution in this paper is the following. 

(a) We present a new higher-order lazy narrowing calculus LNg by extending 
LN. 

(b) We introduce an equation selection strategy that restricts the application 
of outermost narrowing at variable position and enables the application of 
the inference rules that can solve certain flex-flex equations. 

(c) We prove that LNg with strategy is complete (with respect to normalized 
solutions) . 

(d) We show that an eager variable elimination strategy makes our calculus even 
more deterministic for orthogonal pattern rewrite systems. 

As a result we successfully reduce the search space of normalized solutions and 
compute more specific solutions than with LN. 

The rest of this paper is structured as follows. In Sect. 2 we introduce some 
preliminary notions and notations. In Sect. 3 we recall some theoretical results 
about preunification and pattern unification. In Sect. 4 we introduce the un- 
oriented higher-order lazy narrowing calculus LN and state the completeness 
result. In Sect. 5 we define our main calculus LNff. In Sect. 6 we define the 
equation strategy Sn and the class of normal LNff-refutations, and prove that 
all the normalized solutions of a goal are subsumed by substitutions computable 
with normal LN^-refutations. In Sect. 7 we extend our completeness result with 
an eager variable elimination strategy for solving parameter-passing equations. 
Finally we draw some conclusions and directions for further research. 

2 Preliminaries 

We employ the notation a.m,n for a sequence Om, am+i, . . . , a„. We write a„ 
instead of ai If the length of a sequence is irrelevant then we may omit the 
indices and write, e.g., a for an arbitrary (including the empty) sequence of a’s. 
We sometimes denote an empty sequence by the symbol □. 
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A . , is a simply typed lambda-term over a signature T . We distinguish 

bound and free variables at the syntax level; we use uppercase letters X, Y, 
Z, H for free variables, lowercase letters x, y for bound variables, and letters 
l,r, s,t,u,v,w for terms if not stated otherwise. We extend this convention to 
sequences; For instance, x denotes a sequence of bound variables, whereas s„ 
denotes the sequence of terms si, . . . , s„. We denote by XV the set of free vari- 
ables, and by V(t) the set of free variables occurring in a term t. A . . , is a 

term of the form Ax.A(s). A . _ . , is a term which is not flex. A, .. is a 

term with the property that all its flex sub-terms are of the form Ax.A(y) with 
y distinct bound variables. We consider two terms s and t equal, notation s = t, 
if they are a/^ry-equivalent. This notion of equality is extended to substitutions. 
In the sequel we represent terms in long /^ry-normal form. 

Definition 1 (pattern rewrite system) A .. / . (PRS for 

short) is a set of rewrite rules of the form /(I) — > r with / G IF, /(I), r terms of 
the same base type, V(/(l)) 3 V(r) and /(I) a pattern. 

Given a PRS TZ, we denote by ^ the rewrite relation induced by TZ. The 
relations and J, are defined as usual. 

Definition 2 (equation) An ... _ is a pair s « t of terms s 

and t of the same type. An ... . _ is a pair s > t of terms s and t 

of the same type. An . , _ is either an unoriented or an oriented equation. 

A . . . , _ is an equation between flex terms. A . . . equation is 

an equation between a flex and a rigid term. A , .. . , _ is an equation 

between patterns. Ay is a finite sequence of equations. A . . y is a 

goal consisting of flex- flex equations. 

Let 0 be a substitution. We define the . . of 0 as 'D{6) = {X G TV \ X9 yf 

Ajandthe . , . oi9asT{9) {A0 | A G I? (0)}. If 6>i, 02 are substitutions 
and P is a set of variables, we write 0i < 02 [V] if 0i<5 \v= 02 \v for some S. 

Definitions (unifier and solution) A substitution 0 is a . , . 

s and t if s9 = t9. A substitution 0 is a , . , y G if s0 = t0 for every 

equation s « t or s > f in G. 0 is a solution of an equation s « t if s0 <->* t9. 9 
is a , - , . , _ s > t if s0 t0. 0 is a , - , y G if 0 is a 

solution of all equations in G. 

We will make use of the following important property of patterns. Given a PRS 
TZ and a substitution 0, we say that 9 is TZ ... if every term in X(0) is 

7^-normalized. 

Lemma 1 If 7?. is a PRS, A a free variable, y^ distinct bound variables and 0 
a substitution then Ax^.A0(y^) is 7^-normalized iff A0 is 7?.-normalized. 

In the sequel, if not stated otherwise, 7^ is a confluent PRS. We will often 
omit the prefix TZ- when TZ is understood from the context. We denote by TZ+ the 
PRS TZ extended with the rules {A « A ^ true, A > A ^ true}, s ~ t stands 
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for either s w t or f « s. We extend the notation of the binary relations between 
terms to componentwise relations between sequences of terms. For example, 
s„ [> t„ stands for si c> ti, . . . , s„ > tn- We denote sequences of equations by E, F 
and G, possibly subscripted. 



3 Higher-Order Unification 

We start our discussion with the general higher-order unification system PT. 



The system PT. PT is a version of the preunification system proposed by 
Snyder and Gallier [12]. We omit the variable elimination rule in PT since it is 
not necessary for our completeness results. The inference rules for higher-order 
unification are: 

[del],^ Deletion 

Ei,t Ki t, E 2 

El, E2 

[dec],^ Decomposition 

Ei,Xx.v{Sn) » Xx.v{tn),E 2 
Ei,Xx.Sj2 ~ Xx.'t'yi, E 2 

where v € E U {x}. 

[i]~ Imitation 

Fli,Ax.X(s„) » Ax./(t^),F;2 Ei,Xx.f{tm) » Xx.X{Sn),E2 
EiS, Ax.H,^(syi^] ~ Ax.t^(5, E 2 S Ei5, Xx.tijyiS ~ Ax.H^[syj(5), E 2 S 

a f e E where 5 = {X 1 -^ Ax„./(Hm(x„))}. 

[p]~ Projection 



£’i,Ax.X(s„) w Xx.t,E 2 



El, Xx.t « Ax.W(s„),if 2 



EiS, Ax.(si<5)(Hp(s„5)) « Xx.tS, E 2 S EiS, Xx.tS « Ax.(si5)(Hp(s„<5)), E 2 S 

if Xx.t is rigid, where S = {X 1 -^ Ax„.Xi(Hp(x„))}. 

In the inference rules [i]~ and [pjsi, Eli are distinct fresh variables. 



;,s G 2 whenever ■— is an instance of a PT inference 
G2 



Notation. We write Gi 

rule a which computes S. The label can be omitted if it is not relevant or it 
is clear from the context. We sometimes distinguish the selected equation in a 
PT-step by underlining it. The same conventions will be used later when we 
introduce other calculi. 

The following completeness result is known for PT: 



Theorem 1 (Completeness of PT) Let 0 be a unifier of a goal G and V D 
V(G) U 2A(0). There exist substitutions S, 6' and a PT-derivation G F such 
that: (a) F is a flex-flex goal, and (b) 59' = 6 [Pj. 
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A proof of this theorem can be found in [11]. We note here that PT is strongly 
complete, i.e. Theorem 1 holds regardless of the order of selecting equations in 
the goal. 



The system PU. It is well-known that two unifiable patterns have a unique 
(modulo variable renaming) most general unifier. PU is a transformation system 
for pattern unification. It consists of all the inference rules of the system PT and 
the following two inference rules: 

[ffs],^ Flex- flex same equation 



Ai,Ax.X(yJ^Ax.A(y;„),F;2 

{E^,E2)5 

where J = {X i-^ Ay„.iL(zp)} with {zp} = {yi \ I < i < m and yi = y[}. 
[ffd],^ Flex- flex different equation 



£’i,Ax.A(y^) » Xx.Y{y'J,E 2 

{E^,E2)S 



where <5 = {X i-^ Xx^.H{zp),Y ^ Ay„.iL(zp)} with {zp} = {y^} n {y],}. 

H is here a fresh variable, and y, y' are sequences of distinct bound variables. 
We denote by PUd the system consisting of the inference rules of PU with 
El = □. PUd is of interest because of the following property (cf.[8j): 

Theorem 2 (Completeness of PUd) Let s, t be two unifiable patterns. Then 
there exists a PUd-derivation of the form s « t □ with 9 a most general 
unifier of s and t. 



4 Higher-Order Lazy Narrowing 

Lazy narrowing is a goal-directed method for solving goals in equational theories 
presented by a confluent term rewriting system. In the first-order case a calculus 
called LNC [7] has been defined. LNC is sound and complete with respect to the 
leftmost equation selection strategy and several refinements have been proposed 
to reduce its non-determinism. The calculus LN introduced by Prehofer [If] is 
an approach for solving higher-order equations with respect to confluent PRSs. 
Since the calculus LN restricted to first-order terms has many similarities with 
LNC, one could expect that some of the deterministic refinements of LNC can 
be carried over to LN. Our starting point of investigation is the calculus LN 
defined below. It is a generalization of Prehofer’s calculus LN in that we allow 
both unoriented and oriented equations in goals. 

In order to handle oriented equations, we will introduce the following infer- 
ence rules for oriented equations: [dec],^, [deljj^, [i],>, [p]i>, [ffs]|^ and [ffdjj^. They 
are distinguished from the corresponding rules of PU for unoriented equations 
by subscripting them with the equality symbol >. Each new rule differs from the 
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corresponding one only in that it treats oriented equations. For instance, the 
decomposition rule [decj^^ is the same as [dec],^ except that all the occurrences 
of « in the inference rule of [dec],^ are replaced by >. 



The Calculus LN. LN consists of the inference rules [dec],^, [del],^, [i]~, [p]r;, 
[dec]^, [del],^, [i],>, [p]i>, plus the narrowing rules [of],^, [ov]^, [of],„, [ov],^ defined 
below: 

[of]^ outermost narrowing for unoriented equations 

Fii, Ax./(s„) \yj.t,E 2 
El, Ax.s„ [> Ax.l„, Ax.r k, Ax.t, E 2 

[ov].^ outermost narrowing at variable position for unoriented equations 

Ei,Xx.H{Sn) Ax.t, E 2 

EiS, Ax.Hm(sn^) > Ax.l„, Ax.r « Xx.tS, E 2 S 

if Xx.t is rigid, where <5 = {H 1 -^ Ax„./(Hm(x„))}. 

[of]^ outermost narrowing for oriented equations 

Fii,Ax./(sn)i>Ax.t,F;2 
El, Ax.s„ [> Ax.l„, Ax.r > Xx.t, E 2 

[ov]|^ outermost narrowing at variable position for oriented equations 

El, Ax.iJ(s„) > Xx.t, E 2 
EiS, Ax.Hm(sn^) > Ax.l„, Ax.r > Xx.tS, E 2 S 

if Xx.t is rigid, where <5 = {H 1 — > Ax„./(Hm(x„))}. 

In these inference rules are distinct fresh variables and /(Im) ^ r is a fresh 
variant of an x-lifted rule (see [1 1] for the definition of x-lifting) . We write [of] 
to denote [of]^ or [of],^, and [ov] to denote [ov]^ or [ov],^. [o] denotes [of] or [ov]. 
We use letter tt to denote an LN-step and II to denote an LN-derivation. 

It can be easily verified that the calculus LN is sound, i.e. if Gi ^a,s G 2 and 
0 is a solution of G 2 then 56 is a solution of Gi . 

In the sequel we use {...} to denote multisets and >mui for the multiset 
ordering on sets of non-negative integers. The expression |e| may denote: (a) the 
length of e if e is a derivation, or (b) the size of e if e is an equation or a term. 

The use of LN in solving higher-order goals is justified by the following com- 
pleteness result: 

Theorem 3 (Completeness of LN) Let 7?. be a confluent PRS and G a goal 
with solution 6. Then there exists an LN-derivation 77 : G E such that 
5 < 6 [V(G)] and F is a flex-flex goal. 

Proof. (Sketch) The proof of this theorem is along the following lines. We first 
define a suitable well-founded ordering on some structures that encode the fact 
that a substitution is a solution of a goal. 
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Definition 4 Let G = e„ be a goal. We define Repr(G) as the set of triples 
of the form (G,0,R„) with 9 solution of G and R„ a sequence of reduction 
derivations of the form Rj : ~^n+ true. 

On such triples we define the following well-founded orderings: 

~ (e„,6»,R„)>A(e;„,6»',R^) if . . . , \Rn\}>mui{\R[\, ■ ■ ■ ,\Rm\}, 

- {er,,9,Rn)>B{e'^,0',H'J if {|i||ie^(^rv(e„))}>m.i{|^'| | t' G I {9' \ , 

~ (®m Rn) > C (®mi ^ ! ^m) if { l^l 1 1 ■ • ■ i |}> mul{\^l 1 1 • ■ • i |} , 

— is the lexicographic combination of >a, >b, >c- 

Next we prove the following lemma, which is also used in the proof of Lemma 4: 



Lemma 2 Let Go = if i, e, if 2 be a goal with solution 0 q and non-fiex-fiex equa- 
tion e. Assume V D V(Gq) U I?(0o). Then for any triple (Go,0o,R°) G Repr(Go) 
there exists an LN-step tt : Go = if 1 , e, A 2 =^a,s Gi and a triple (Gi,0i,R^) G 
Repr(Gi) such that: (a) (Go,0o,R°) ^ (Gi,0i,R^), and (b) 9q = S9i [V]. 

We omit the proof of this lemma since it is similar to the proof of Theorem 6.1.1 
in [11]. 

Finally, we note that repeated applications of Lemma 2 starting from a triple 
(Go,0o,R°) G Repr(Go) produces the desired LN-derivation. □ 

Remark 1 1. The substitution <5 in Theorem 3 is a pattern substitution^, since 

it is a composition of pattern substitutions. 

2. LN is strongly complete, namely it does not depend on the order of selecting 
the non-fiex-fiex equations in the goal. 

5 The Calculus LNff 

In this section we introduce our main calculus. 



The calculus LNff. LNfj consists of the inference rules of LN and the rules 
[ffs]^, [ffd]«,, [ffd]^. 

In the sequel we omit the subscripts ~ and > of inference rules a~ and «|> 
and write a when we treat the inference rules collectively. 

We now obtain a more powerful calculus since all the rules for pattern unifica- 
tion are available. Unfortunately the calculus LNfj is no longer strongly complete 
as we can see from the example below: 

Let TZ = {/(W, a) b} and the goal 

Go = f{X,a)>Z,Z ^Y,b>Y,Z>f{X, a) 



^ A substitution 0 is a pattern substitution if every term in I (9) is a pattern. 
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with solution 6 = {Z f{X,a),Y i— > b}. If we select the equation Z Ki Y 
to solve the goal Go then the only applicable rule is [ffdja;. Hence we have the 
following derivation: 

Gi = fiX,a)>H,b>H,H>f{X,a) 

It can be easily seen that the goal Gi has no solution. Hence, LN® is not strongly 
complete. □ 

Note that the previous example does not refute the strong completeness of LN 
because no rule of LN can act on the flex-flex equation Z « K 

In the following we show that there exists an equation selection strategy Sn 
with respect to which the calculus LNff is complete. Actually we show a stronger 
result: by adopting the calculus LNfj with strategy we achieve two important 
desiderata: 

1. We eliminate the nondeterminism due to the choice of the equation in a goal 
to be solved next, 

2. We restrict the application of outermost narrowing at variable position; as 
a consequence, a smaller search space for solutions is created. 

The steps of our investigation can be summarized as follows: 

1. We first observe that if we know that the solution of a goal is normalized 
with respect to certain variables then we can apply the rules [ffs] and [ffd] to 
certain pattern equations and safely avoid the application of [ov] to certain 
flex-rigid or rigid-flex equations (Lemma 3 and Lemma 4) . 

2. We identify sufficient conditions which guarantee that the solution of a goal 
is normalized with respect to certain variables (Lemma 5). 

3. Based on 2., we define a strategy Sn- For the calculus LN® with the strat- 
egy Sn we identify the class of normal LN^-refutations and prove that any 
normalized solution of a goal G is subsumed by a substitution which is com- 
putable with a normal LNfj-refutation that starts from G (Theorem 4). 

Before starting to describe in detail the steps mentioned above, we note some 
similarities between the calculi LNC and LNff when we restrict ourselves to 
first-order terms: 

1. It can be verified that LNff subsumes LNC with the rule [v] restricted to 
equations between variables. 

2. A [v]-step in LNC can be simulated in LNff by a sequence of [i]-, [p]-,[ffs]-, 
and [ffd]-steps. Since LNC with leftmost equation selection strategy 5ieft is 
complete [7], we conclude that the calculus LNff without [ov]-rules is com- 
plete if we adopt the strategy 5ieft. 

3. Middeldorp . [7] conjecture that LNC is complete with respect to any 

strategy that never selects descendants of an equation created by an outer- 
most narrowing step before all descendants of the corresponding parameter- 
passing equations created in that step have been selected. If this conjecture 
holds then we can replace iSieft with such a strategy and retain the complete- 
ness of LNff without [ov]-rules. 
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Note that the substitution 9 in Example 1 is not normalized. We noticed that 
the normalization of substitutions restricted to the so called - _ - . is 

crucial to restore completeness of LN^. 

Definition 5 (critical variable) The set Vc(e) of - _ - , of an equa- 

tion e is V(s) U V{t) if e = s « t and V(s) if e = s > f. 

We first prove the following technical lemma. 

Lemma 3 If Gp = Ei,e,E 2 =>[ff],5o fvcle) is normalized then for 

any (Go,0p,R°) G Repr(Gp) there exists a solution 9i of Gi and (Gi,0i,R^) G 
Repr(Gi) such that: (a) (Gp,0o,R°) (Gi,0i,R^), and (b) 6q = Sq9i. 

Proof. Let (Go,0p,R°) G Repr(Gp). The proof is by case distinction on the 
shape of e. 

(i) If e = Ax.X(y^) « Ax.F(y'„) then Ax.X(y„)6»p | Ax.r(y'„)6>p because 6»p is 
a solution of e. In this case Vc(e) = {X,Y} and therefore the terms X6q and 
Y9q are normalized. By Lemma 1 the terms Ax.X(y^)0p and Xx.Y{y'^)9o are 
also normalized. Hence the equality Ax.W(y^)0p = Xx.Y{y'^)9o holds, i.e. 9q is 
a unifier of Ax.X(y^), Ax.y(yJ^). Since (5p is a most general unifier of Ax.X(y^) 
and Ax.y(y(j) there exists a solution 9i of Gi such that 9q = S9i. The construc- 
tion ofR^ such that (Gp, ^p, R°)=a(Gi, 6»i, R^) and (Gp,6»p,R°)>b(Gi,6Ii,R^) 
is straightforward. Therefore, (a) holds as well. 

(ii) The case when e = Ax.Af(y^) « Ax.X(y(^) can be proved in a similar way. 
(ill) Let e = Ax.X(y^) c> Ax.F(y(j). Because 9q is a solution of Ax.X(y^) c> 
Ax.y(y(j), we have Ax.X(y^)0p — >* Ax.y(y(j)0p. In this case we have Vc(e) = 
{X} and thus XOq is normalized. By Lemma 1 the term Ax.Af(y^)0p is also 
normalized. Therefore 6q is a unifier of the terms Ax.X(y^)0p and Ax.F(y(j)0p. 
Since (5p is a most general unifier of Ax.X(y^) and Ax.y(y(j) there exists a solu- 
tion 9i of Gi such that 9q = The construction of R^ such that (Gp, 0p, R°)=^ 
(Gi,0i,R^) and (Gp, 0p, R°)>_b(Gi, 0i, R^) is straightforward. Therefore, (a) 
holds as well. 

(iv) The case when e = Ax.X(y^) > Ax.X(y(„) can be proved in a similar way. 

We next investigate restrictions under which the rules [ov],^, [ov]|^ can be 
eliminated without losing the completeness of LN®. The next example illustrates 
that in general we can not drop [ov] without loss of completeness. 

Consider the PRS TZ = {f{g{X)) — > X} and the goal Z{g(a)) « a. 
Obviously the normalized answer {Z i— > Xx.f{x)} could not be computed by 
LNff if we dropped the [ov]-rule. □ 



Lemma 4 Let 9q be a solution of a goal Gq = Ei, e, E2 with e = Ax.X(y) ~ t 
or e = Ax.X(y) >t, where t is a rigid term and Ax.X(y) is a pattern. Assume 
V 3 V(Gp) U T>{9q). If X9o is normalized then for any (Gp,0p,R°) G Repr(Gp) 
there exists an LNg-step t: : Gq = Ei,e, E2 =^q Gi with a yf [ov] such that: 
(a) (Gp,0p,R°) ^ (Gi,0i,Ri), and (b) 0p = So0i [Rj. 
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Proof. By Lemma 2, there exists an LN-step tt which satisfies conditions (a) 
and (b). If a = [ov] then the term Ax.X(y)0o is reducible. This implies that X6q 
is reducible, which contradicts our hypothesis. Hence a yf [ov]. □ 



6 Normal LNf^Refutations 

We will use the results of Lemmata 3 and 4 in order to define a suitable equa- 
tion selection strategy with respect to which the calculus LNg is complete. 
The success of defining such a strategy depends on the possibility to determine 
whether the solution of an equation is normalized with respect to certain vari- 
ables. In the sequel we look for such normalization criteria. 

The notions of. , , ..... . . ... (ILD for short) and of. , ... 

. . of the selected equation in an LN^-step are defined as shown in the 

table below. In the table, the symbol =■ stands for either w or > (but the same 
in the same row). The superscripts 1 and 2 on [i] and [p] distinguish the first 
and the second case of the corresponding inference rule. 



rule 


ILD 


immediate descendant 


[of] 


Ax.r = '^ Ax.t 


Ax.s„ > Ax.l„, Ax.r =' Xx.t 


[ov] 


Ax.r =■ Ax.t 


Ax.Hm(s„^) [> Ax.l„, Ax.r =• Xx.tS 


[dec] 


Ax.s„ =■ Ax.t„ 


Ax.s„ =■ Ax.t„ 


[iJ^ 


Ax.H772(syj^) =■ Ax.t^T^^ 


Ax.Hyj^(s77,^) =■ Xx..ti>uiS 


[iJ^ 


Ax.tyj^J =■ AX.Hyjq,(S7T,^) 


Ax.tyjq,j =■ AX.Hyj^(S77,^) 




Ax.(si^)(Hp(s„<5)) =■ Ax.u(t^(5) 


Ax.(si5)(Hp(s„<5)) =■ Ax.ri(tm^) 


[P]^ 


Ax.u(tm(5) =• Ax.(si^)(Hp(s„(5)) 


Ax.u(tm(5) =■ Ax.(si5)(Hp(s„<5)) 


[del] 

[ffs], [ffd] 


- 


- 



Descendants and ILDs of non-selected equations are defined as expected. The 
equations Ax.s„>Ax.l„ and Ax.Hm(sn(5) > Ax.l„ created in an [of]-step and [ovj- 
step respectively, are called , . , . > , , _ created by that step. 

The notion of . . . is obtained from that of immediate descendant by 

reflexivity and transitivity. The . relation is defined as the inverse of the 
descendant relation. 

Definition 6 (precursor) Let U : Gq =>* Ei,ei, E 2 ,e 2 , be an LNff-deriv- 
ation. 6 i is a, of 62 in 77 if there exists an equation e which is subjected 

to an [o]-step tt in 77 such that (a) e \ is a descendant of a parameter passing- 
equation created by tt, and (b) 62 is a descendant of the ILD of e in tt. 

Given an LNff-derivation 77 : Go Gn = Ei,e, E 2 , we denote by prec 77 (e) 
the sub-sequence of equations of G^r that are precursors of e in 77. 



Definition 7 (regular transformation) Let Go, Gi be goals with (Go, Oq, R°) 
€ Repr(Go), Gq = Ei,e,E 2 and (Gi,0i,R^) e Repr(Gi). Assume V D V(Gq) U 
T>{6q). a transformation step (Go,6>o,R°) (Gi,0i,R^) is y, if: 
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— e is a non-flex-flex equation and there exists an LN-step tt : Ei,e, E2 =^a,s Gi 
such that the conditions (a) and (b) of Lemma 2 hold, or 
~ 6q tvc(e) is normalized, Go = Ei,e,E 2 =^[fi ],5 Gi and the conditions (a) and 
(b) of Lemma 3 hold. 

Lemma 5 Let Go be a goal with normalized solution and {Go,6q,'RP) G 
Repr(Go). If (Go, 9q, R°) . . . => (Gat, 9n, R^) is a sequence of regular trans- 
formation steps and II : Go => 5 o Gi ••• Gn is the corresponding 

LNff-derivation then for any e G Gn with precy 7 (e) = □ we have that 6n fvole) 
is normalized. 

Proof. Let be the ancestor of e in Gi and 7 i = SiSi+i . . . Sn-i (0 < j < N). 
We prove a slightly stronger result: 0Arfvc(ei7i) is normalized for any 0 < i < N. 
It is easy to see that this implies the normalization of 07vtvc(e)- 

We first introduce the notion of [o]-ancestor. We say that an ancestor e' of e 
is an [o]- . of e if we have 



n :G^* E^, I, E 2 Eia,Eii,e",E 2 a^* E[,e,E'^. 

(That is, an [o]-step is applied to e' and e descends from the ILD of e'.) We 
prove by induction on i (0 < f < N) that 9n rvc(e, 7 i) is normalized. Let tt^ be 
the i-th step of II. 

If i = 0 then 9n fvc(eo 7 o) i® normalized because 'Jo9n = 9q [Vc(eo)] and is 
normalized. 

We next show that rVo(ei+i 7 i+i) is normalized if 9n Ivdei-yi) is normalized. 
Suppose Ci is not an [o]-ancestor. We show Vc(ei+i) C VdciSi) by the follow- 
ing case distinction. 

(a) TTi is an [o]-step. Since is not an [o]-ancestor, we have that Ci+i is a 
parameter-passing equation created by the f-th step of II and therefore 
I^c(Ci-l-l) G Vc(c 2 Ji). 

(b) TTi is not an [o]-step. If is unoriented then Vc(ei+i) = V(ei+i) C V(eiSi) = 
VcieiSi). If Ci is of the form si><: then it can be shown by case distinction on 
TTi that Vc(ei+i) C V(s(5) = Vci,eiS). 

The induction hypothesis yields the normalization of 9n rVc(ei« 5 i 7 i+i)- Hence 
the above inclusion implies the normalization of 9n rVc(ei+i 7 i+i)- 

Suppose Ci is an [o]-ancestor. Then = Ax./i(s„) =’ Ax.f or ti = Ax.t « 
Ax./i(s„) and II is of the form 

^ : Go G, = ifi,e,G 2 

Gi+i =Gi5i,Ax.w„i>Ax.l™,Ax.r =■ Xx.tSi,E2Si 
Gn = E[,6,E!,. 

Since prec 77 (e) = □ we have 

(Ax.w„ > Ax.l„)5i+i . . . T. 
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We show that the following relation holds: 

67i (^x.r =■ Ax.Mi)7i+i. (1) 

li h = f then we have 5i = e, n = m and Ax.w„ = Ax.s„. Since . . . Sn-i 
is a solution of Ax.s„ > Ax.l„ we learn that Ax.Sj 7 i+i — >* xdj 7 i+i for 1 < j < n 
and therefore Xx.h{sn)ji — *■* Ax./(l„ 7 i+i) ^ Ax.r 7 i+i. 

Otherwise h G TV and in this case we have 5i = {h ^ Ax„./(Hm(x„))} 
and Ax.Wm = Ax.Hm(s„<5i). Because 7 j+i is a solution of Ax.Wm > Ax.l^ we 
have Ax./i(s„)7i=^Ax./(H^(s„(5i)7i+i) Ax./(l„ 7 i+i) = Ax./(l„) 7 i+i ^ 

Ax.r7i+i. 

Thus in both situations we have Xx.h{sn)"fi Ax.r 7 i+i and hence (1) holds. 

It follows that Vc(ei+i 7 i+i) C Vdei'ji). Since On \vc(ei-yi) is normalized, the 
substitution On rVo(ei+i 7 i+i) is normalized as well. □ 

We are ready now to define our equation selection strategy for LNfj. 

Definition 8 (strategy 5„) An LNfj-derivation II respects the strategy if 
for any subderivation II' : Go =^* Gm = Ei,e,E 2 of II we have: 

(cl) If [ffs] or [ffd] is applicable to e then precy 7 /(e) = □. 

(c2) If e is of the form Ax.A(s) ~ t or Ax.A(s)>t, with t rigid and precyj/(e) yf □ 
then all the selectable equations of Gm satisfy condition (c2). 

Condition (cl) enables the selection of an equation e to which [ffs]- or [ffd]-rules 
are applicable only when e has no precursor. Condition (c2) enables the selection 
of equations to which [ov]-rules are applicable only when there is no other choice. 



Definition 9 (normal LNf^refutation) An LNfj-derivation II : Gq =>* E is 

a ff if 

1. n respects and 

2. F does not contain equations which are selectable with Sn- 

Completeness. We will prove that LNff with strategy Sn is complete with 
respect to normalized solutions. 

Theorem 4 For any normalized solution Oq of a goal Go such that V(Gq) U 
V{0) C V there exists a normal LNff-refutation 77 : Go F with S < 0 [V]. 

Proof. Assume (Go,0o,R-°) & Repr(Go). Let 

A: (Go,0o,R°) ^ (Gi,0i,Ri) ^ ^ {Gn,0n,'R^) 

be a maximal sequence of transformation steps starting from (Gi,0i,R^) such 
that the corresponding LN^-step iTi : Gi ^ G^+i satisfies strategy 5„. The 
existence of the sequence A is a consequence of the fact that =^C;^ and is 
terminating. It suffices to show that the LNfj-derivation ttq • • ■ ttn-i is a normal 
LNff-refutation, which is obvious. □ 
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7 Eager Variable Elimination 

We address here the eager variable elimination problem for LNfj with respect 
to normal LNfj-refutations. In the first-order case this problem is related to 
the possibility to apply the variable elimination rule prior to other applicable 
inference rules. In [6] it is shown that an eager variable elimination strategy for 
parameter-passing equations is complete for left-linear confluent TRSs. 

The proof is mainly due to the standardization theorem for left-linear con- 
fluent TRSs, which roughly states that if a term s is reachable to a term t then 
an outside-in reduction derivation from s to t exists. 

We will generalize the first-order eager variable elimination strategy to LNfj 
with the help of outside-in reduction derivations. 

Definition 10 An LNfj refutation II . .. ^ . , . . _ 

. . y . if [o]> is never applied to rigid-flex equations of the form Ax.s > Ax.A(t) 

in n. 

We say that # . - - - - - . 

, if for any goal G with a solution 9 there exists an LNff refutation 

G =>* □ that respects the eager variable elimination strategy with a <ji 9, 
when TZ belongs to the class of PRSs. 

The notion of outside-in reduction derivations for orthogonal PRSs is carried 
over from that of first order TRSs [13] except for the definition of anti-standard 
pairs stated below. 

Definition 11 (outside-in reduction derivation for orthogonal PRSs) 

An 7?.+-reduction derivation by an orthogonal PRS is called , - . if every 

subderivation e — eo e„ e' satisfies the following condi- 

tion: it p > q > e and all Pi {1 < i < n) are disjoint from p then p/q is above 
or disjoint from any free variable position in L Here p/q is a position satisfying 
p= q - {p/q). 

The only difference from the first-order case given in [6] is disregard for the 
bound variables below the free variables. The definition above states that the 
subterms headed by free variables in a higher-order pattern, called the - y 
after Oostrom [10], are regarded as mere variables. 

In [10] Oostrom claimed that the following statement holds, which allows us 
to concentrate on only the outside-in reduction derivations. 

Theorem 5 For any rewrite derivation s t by an orthogonal PRS TZ, there 
exists an outside-in rewrite derivation from s to f. □ 

We follow the same line of reasoning as in [7] to show that the eager vari- 
able elimination strategy for parameter-passing equations preserves completeness 
of LNff: first we introduce a property of reduction derivations which holds for 
any outside-in reduction derivation starting from a goal consisting of unoriented 
equations. Next we show that regular transformations preserve this property. 
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This result motivates the possibility to inhibit the application of [o] to equations 
of the form Ax.s > Ax.X(y). 

First we introduce a class of restricted outside-in reduction derivations. 

Definition 12 Let TZ be an orthogonal PRS and st>t6 true an outside-in 
72,+-reduction derivation. Then we say the derivation has property Vho if every 
reduction step in it satisfies the following condition: if a position 1 - p is rewritten 
in the reduction step and later steps except the final step do not take place above 
1 • p, then p is above or disjoint from any free variable position in t. 

Let (G, 9, R) G Repr(G) such that every reduction derivation in R is outside- 
in. It is obvious that all the outside-in reduction derivations in R have property 
Vho if the goal G consists only of unoriented equations. The following lemma 
establishes the preservation of the property Vho during regular transformations. 

Lemma 6 Let (G, 0, R) G Repr(G) and suppose (G',0',R’) is obtained by a 
regular transformation from (G, 0, R) . If R only consists of outside-in derivations 
with property Vho, then the same holds for R^ □ 

The proof is done by an easy but tedious case analysis on the regular transfor- 
mations. 

Theorem 6 LNfj with eager variable elimination strategy is complete for or- 
thogonal PRSs with respect to normalized solutions for goals consisting of un- 
oriented equations. 

Proof. Let (G, 0, R) G Repr(G), where G consists of unoriented equations, 0 is 
a normalized substitution, and R contains an outside-in reduction derivation R. 
Note that R has no extended anti-standard pairs. For any (G',0',R^) obtained 
by the repeated applications of regular transformations, from Lemma 6 we learn 
that if G' includes an equation e of the form Ax.s0' > Ax.X0'(t0') then the 
corresponding reduction derivation in R' should be e — true; otherwise R^ 
has an extended anti-standard pair. The regular transformation applied to the 
equation e never produces an [o]-step. □ 

Note that once we get outside-in reduction derivations, we no longer need the 
restriction on terms to patterns. The restriction, however, becomes crucial for 
further eager variable elimination. For instance, [ov],> may be applied to a flex- 
rigid parameter-passing equation with non-pattern in the left-hand side. On the 
other hand, from Lemma 5 and Lemma 6 we infer that normal LNff-refutations 
never contain applications of [ov],>-steps to flex-rigid parameter-passing equa- 
tions with pattern in the left-hand side provided we are interested only in nor- 
malized solutions and the precursors of the equation were completely solved. In 
practice, we expect that most terms occurring in LNfj derivations are patterns 
and hence [ov]i> is rarely employed. 

The above remark assures that normal LNff refutations that respect eager 
variable elimination strategy enjoy a generalization of the eager variable elimi- 
nation strategy in the first order case. Recall that eager variable elimination is 
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also applicable to parameter-passing equations of the form X>tin the first order 
case [6]. Since X is obviously a pattern, we can prohibit the application of [ov] 
to this equation. 



8 Conclusions and Further Research 

We identified an equation selection strategy class with respect to which the 
calculus LNff is complete. Note that does not identify the equation which 
must be selected next but specifies a condition which must be satisfied by the 
selected equation. Therefore it is possible to define more specific equation selec- 
tion strategies for LNg. Such a strategy is the one that always selects an equation 
which satisfies and has small nondeterminism due to the selection of the ap- 
plicable inference rule. Also, our result confirms the validity of the conjecture of 
Middeldorp which we mentioned in Sect. 5. 

In Sect. 7 we proved that if we restrict ourselves to an orthogonal PRS then 
we can make the calculus LNff even more deterministic by adopting an eager- 
variable elimination strategy. 

We mention here the result of Prehofer [11] about the possibility to com- 
pletely drop the [ov]-rules from LN if we restrict to convergent PRS. The proof 
is based on the existence of innermost derivations for such rewriting systems. 
However, the termination condition is very strong in practice. 
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Abstract. We describe a new approach to higher-order narrowing com- 
putations in a class of systems suitable for functional logic programming. 
Our approach is based on a translation of these systems into ordinary 
(first-order) rewrite systems and the subsequent application of conven- 
tional narrowing strategies. Our translation is an adaptation to narrow- 
ing of Warren’s translation, but unlike similar previous work, we preserve 
static type information, which has a dramatic effect on the size of the 
narrowing space. Our approach supports sound, complete, and efficient 
higher-order narrowing computations in classes of systems larger than 
those previously proposed. 



1 Introduction 

Functional logic languages generalize functional languages by supporting the 
evaluation of expressions containing (possibly uninstantiated) logic variables. 
Narrowing is an essential component of the underlying computational mechanism 
of an internationally supported unified functional logic language [4]. In recent 
years a considerable effort has been invested in the development of narrowing 
strategies. The results of this effort are satisfactory for first-order computations. 
Higher-order narrowing, the situation in which a computation may instantiate 
a variable of functional type, is still evolving. 

The most fundamental question is what universe of functions should be con- 
sidered as possible instantiations for variables of functional type. One attractive 
answer is to consider just those functions (perhaps partially applied) that are 
explicitly defined in the program already, or a user-specified subset of these 
functions. For example, consider the program 

data nat = z I s nat 
data list = [] I nat: list 
compose (F,G) X = F (G X) 
map F [] = [] 

map F (H:T) = (F H) : (map F T) 

* This work has been supported in part by the National Science Foundation under 
grant CCR-9503383. 
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and abbreviate s z with 1, s 1 with 2, etc. The goal map G [1,2] == [2,3] 
would have the solution {G s}, the goal map G [1,2] == [3 , 4] would have 
the solution {G compose (s , s)}, but the goal map G [1,2] == [2,4] would 
have no solutions. 

This approach is quite expressive, and also relatively easy for the program- 
mer to understand. Moreover, there is a very reasonable approach to solving 
higher-order problems of this kind by translating them into equivalent first-order 
problems, in which unapplied and partially applied functions are represented by 
constructors and implicit higher-order applications are made into explicit first- 
order applications. This idea dates back to Warren [13] for logic programs and 
to Reynolds [11] for functional programs. Hanus [7,8] shows how this idea works 
for dynamically typed languages. Gonzalez-Moreno [5] adapts the same idea to 
untyped narrowing. 

Our contribution is to define this transformation for . . _ . . . , . source 

and target languages. We give a rigorous presentation for monomorphic pro- 
grams and sketch an extension to polymorphic programs. The benefits of a typed 
source language are well known. The benefits of maintaining types during pro- 
gram transformation and compilation are becoming increasingly recognized in 
the functional programming community (e.g., [14,15]); these include the abil- 
ity to use efficient, type-specific data representations, the ability to perform 
optimizations based on type information, and enhanced confidence in compiler 
correctness obtained by type-checking compiler output. In functional logic pro- 
gramming, typing the target language has additional dramatic, immediate effects 
on the narrowing space; in particular, typing allows possibly infinite, extraneous 
branches of the narrowing space to be avoided. This obviously improves the effi- 
ciency of the language, and avoids run-time behaviors, especially for sequential 
implementations, that would be unintelligible to the programmer. 



2 Background 



The most recent and comprehensive proposals of higher-order narrowing strate- 
gies differ in both the domain and the computation of the strategy. Gonzalez- 
Moreno [5] considers y . . Rules in these systems are constructor- 

based, left-linear, non-overlapping, conditional, and allow extra variables in the 
conditional part. A translation inspired by Warren [13] removes higher-order con- 
structs from these systems and allows the use of (first-order) narrowing strategies 
for higher-order narrowing computations 

Nakahara et al. [10] consider first-order , . . _ constructor-based orthog- 

onal rewrite systems. A rule’s left-hand side in these systems allows variables 
of functional type, but prohibits both the application of a variable to subterms 
and the presence of a function symbol in a pattern. The strategy proposed for 
these systems is computed by a handful of small inference steps, where “small” 
characterizes the fact that several inferences may be necessary to compute an 
ordinary narrowing step. 
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Hanus and Prehofer [6] consider .. y . _ inductively sequential systems. 

An operation in these systems has a definitional tree in which the patterns may 
contain higher-order patterns [9] as subterms and the application of variables 
to subterms. The strategy proposed for these systems is again computed by a 
handful of small inference rules that, when concatenated together, for the most 
part simulate a needed narrowing computation. 

The domains of these strategies have a large intersection, but none is con- 
tained in any other. For example, applicative orthogonal systems include Berry’s 
system, which is excluded from inductively sequential systems; higher-order in- 
ductively sequential systems allow higher-order patterns in left-hand sides, which 
are banned in SFL programs; and SFL programs use conditional rules with extra 
variables, which are excluded from applicative systems. All the above strategies 
are sound and complete for the classes of systems to which they are applied. 

While first-order narrowing is becoming commonplace in functional logic 
programming, the benefits and costs of higher-order narrowing are still being 
debated. Factors limiting the acceptance of higher-order narrowing are the po- 
tential inefficiency of computations and the difficulty of implementations. In 
this paper we describe a new approach to higher-order narrowing that ad- 
dresses both problems. Our approach is based on a program translation, similar 
to [3,5,11,12,13], that replaces higher-order narrowing computations in a source 
program with first-order narrowing computations in the corresponding target 
program. Our approach expands previous work in three directions. 

(1) We use a translation [12] that preserves type information of the source 
program. Type information dramatically affects the size of the nar- 
rowing space of a computation. 

(2) We present our technical results for the same class of systems dis- 
cussed in [10]. We will argue later that our approach extends the 
systems considered in [5] and with minor syntactic changes extends 
the systems considered in [6], too. 

(3) For a large class of source programs of practical interest [4], our 
approach supports optimal, possibly non-deterministic, higher-order 
functional logic computations [1] without the need for a higher-order 
narrowing strategy. 



3 Language 

3.1 Basics 

We describe our approach with reference to a monomorphically typed functional 
logic language L, whose abstract syntax is specified in Figure 1. For ease of pre- 
sentation, we explicitly type all functions, constructors, and variables, but types 
could be inferred (and we therefore omit some typing information in the con- 
crete examples in this paper) . The abstract syntax is something of a compromise 
among the conventional notations for functional programs, logic programs, and 
rewrite systems. The concrete syntax of functional logic languages that could 
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benefit from our approach could be much richer, e.g., it could allow infix op- 
erators, ad-hoc notation for numeric types and lists, nested blocks with locally 
scoped identifiers, anonymous functions, etc. Programs in languages with these 
features are easily mapped to programs in our language during the early phases 
of compilation. Thus, our approach is perfectly suited for contemporary func- 
tional logic languages, too. 



(algebraic types) 


d 


:= identifier 




(types) 


t 


;= d 


(algebraic types) 






(tl,...,tn) 


(tuples; n > 0) 






(t^t) 


(functions) 


(variables) 


V 


:= identifier beginning with upper-case letter 


(constructors) 


c 


= identifier 




(functions) 


f 


= identifier 




(symbols) 


s 


= c\ f 




(problems) 


problem 


{program, goal) 




(programs) 


program 


:= deci . . . deCm rulei . . . rule-n 


(m, n > 0) 


(goals) 


goal 


~ (vi : tl, . . . ,Vn ■■ tn) ei == 62 


(vi disjoint) (1) 


(constr. deck) 


dec 


:= c : ti ^ ^ t„ ^ d 


(n = ar(c)) 


(function rules) 


rule 


:= f Pi ... Pn = e 


(n = ar(f)) 


(patterns) 


P 


~ (v : t) 


(variable) 






(C Pl...Pn) 


(constructor; n < ar(c)) 






if Pi ■■■Pn) 


(function; n < ar{f)) 






{pi,...,Pn) 


(n > 0) (tuple) 


(expressions) 


e 


:= V 


(variable) 






s 


(constructor or function) 






(d, . . . , Cn) 


(tuple) 






(ei 62) 


(application) 


Fig. 1. Abstract syntax of functional logic language L 


. By convention, type ar- 


rows associate to the right and expression applications associate to the left. Each 



symbol s has a fixed associated arity, given by ar(s). Only partially-applied func- 
tion symbols are allowed in a pattern. 



A, y , is a collection of . , . declarations and,, _ definitions. 
Constructors and functions are collectively called . . ; we use identifiers not 

beginning with upper-case letters for symbol names. Each symbol s has a unique 
associated non-negative arity, given by ar(s). A function definition consists of 
one or more , (not necessarily contiguously presented); each rule has a left- 
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hand side which is a sequence of , .. and a right-hand side which is an 
- . . All the rules for a function of arity n must have n patterns. The 
patterns control which right-hand side(s) should be invoked when the function 
is applied; they serve both to match against actual arguments and to bind local 
variables mentioned in the right-hand side. Patterns are , , - , i.e., 

they are built from , . , , fully-applied constructors, partially-applied func- 
tions, and , . This definition of “ , , - ” generalizes the one in [10], in 

that it permits partially-applied functions. In the logic programming tradition, 
we reserve identifiers beginning with upper-case letters for variables. Expres- 
sions are built from symbols, variables, tuples and binary application denoted 
by juxtaposition. Intuitively, function applications evaluate to the right-hand 
side of a matching rule, and constructor applications evaluate to themselves. 
Parentheses in expressions are avoided under the convention that application is 
left associative. 

Functions (and constructors) are - . ; that is, a function / of arity 
'^^(/) > 1 is applied to only one argument at a time. This permits the ma- 
nipulation of partially-applied functions, which is fundamental to expressing 
higher-order algorithms involving non-local variables. Unlike conventional func- 
tional and functional logic languages, which treat functions as black boxes, we 
permit matching against unapplied or partially-applied functions (or construc- 
tors). We delay the discussion of this feature until Section 6 when we compare 
our approach with [6]. It is often useful (particularly in presenting the result 
of our translation system) to describe uncurried functions that take their argu- 
ments “all at once;” this is done by specifying an arity-1 function taking a tuple 
argument. 

A . (Pi ff) consists of a program p and a goal g. A consists of a 

sequence of variable declarations followed by an , , _ . , an expression of the 

form 6 i == 62 . Any variables appearing in ei or 62 must appear in a declaration. 
There is no loss of generality in restricting goals to equations. A problem , _ 
is a substitution 9 (see Sect. 3.4) from the variables declared in the goal to 
applicative terms, such that 9(ei) and 0 ( 62 ) reduce to the same applicative term. 

3.2 Typing 

L is an explicitly typed, monomorphic language. Types include algebraic types, 
whose values are generated by constructors; tuple types; and function types. 
The typing rules are specified in Figure 2 as a collection of judgments for the 
various syntactic classes. The judgment E \~ class, - : t ^ E' asserts that 

. . of syntactic category . . is well-typed with type t in environment E, 
and generates an environment E'] judgments for specific classes may omit one or 
more of these components. Environments map symbols and variables to types. 
Note that all functions are potentially mutually recursive. 

Each variable declaration (in rules or goals) has an explicit type annota- 
tion; together with the typing rules these allow us to assume the existence of 
a well-defined function , (), mapping each (well-typed) expression or pat- 
tern to its type. A solution substitution {vi 1 — > e^} is well- typed if and only 
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\-program, program ^ E E \-goal goal 
^problem {program, goal) 



^ dec deCl =r* E\ ... 1 “ dcCrn — ^ Em 
^ ^ rule rulc\ =r* Em-\-l ... E \~ y-y/g rulCn — ^ Em-\-n 
E = El + . . . + Em+n 
\-program deci . . . deCm rulei . . . rule„ ^ E 

E + {vi tl, . . . , tn} he Ci t{i — 1, 2) 

^ ^ goal (^1 • ili • • • • tn) Cl == 62 



I dec o . tl ^ ^ tn ^ d {c I ^ ^ ^ in ^ dl" 

E{f) = ti ^ ^ tn ^ t E \-p Pi : ti^Ei{l < i < n) E + Ei + . . . + En \~e e : t 

^ ^rule f Pi* • • Pu ~ 6 ^ {/ I ^* tl tn ^ i} 



E \-p {v : t) : t ^ {v 1-^ t} 

E{c) = ii — > . . . ^ i„ ^ d E \-p Pi : ti ^ Ei{l < i < n) 
E \-p {c Pi . . .pn) '■ d ^ El + ... + En 

E{f) = ii — » . . . ^ in ^ i E \-p Pi : ti ^ Ei{l < i < m) 

E ^p if Pi ■ . . Pm) ■ tm+l ~^...^tn^t^El+... + Em 

E \-p Pi : ti ^ Ei{l < i < n) 

E \-p {pi, . . . ,Pn) : {tl, . . . ,tn) ^ El + . . . + En 



E{v) = t E{s) = t 

E \~e V : t E \~e s : t 

E \~e a : ti{l < i < n) E \~e ei : t2 ^ t £ he 62 : i2 

E he {ei, . . . ,6„) : (ii, . . . ,in) E he (6162) : i 

Fig. 2 . Typing rules for language L. The environment union operator E\ + E2 is 
defined only when Ei and E2 agree on any elements in the intersection of their 
domains. 



if Vi,.-, , {vi) = ... , {ci). In practice, we could generate the type annota- 

tions for L automatically by inference from a source program with missing or 
incomplete type annotations. 
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3.3 Relationship to Term Rewriting 

A program p may be viewed as a rewrite system (A, TZ) where 

— A is a - y , i.e., a set of symbols (partitioned into functions and con- 
structors), with associated types, consisting of those symbols that appear in 

— 72. is the set of / - . consisting of the function rules in p. 

In the terminology of [10], our system is an , , . _ , . ^ y . . 

(.4TRS) using our slightly generalized notion of , . - . . We do not 

specify other fundamental properties, such as left-linearity, or non-overlapping 
of rules, though each of these may be useful in practice. For simplicity of pre- 
sentation, we prohibit extra variables on the right-hand sides of rules, but these 
could be added similarly to goal variables without fundamental difficulty, as 
could conditions to the rules. 

3.4 Evaluation 

This view of programs as rewrite systems defines the notion of evaluation for 
our system. We define the evaluation of variable-free expressions as ordinary 
rewriting. An expression is in normal form if it cannot be further rewritten. 
Orthogonal (left-linear and non-overlapping) programs will be confluent, but 
not necessarily terminating. Well-typed expressions enjoy the , , . . , _ 

property, which says that their type is invariant under reduction. 

As noted above, a problem solution is a substitution from the variables de- 
clared in the goal to applicative terms. This definition doesn’t indicate how a 
solution might be found. To be more concrete, we define the evaluation of a 
problem to mean the computation of a solution substitution by a sequence of 

y steps. Formally, a , , . is a mapping from variables to terms 

which is the identity almost everywhere. Substitutions are extended to homo- 
morphisms from terms to terms. The narrowing relation on 72, denoted is 

defined as follows: e '^g p i=r e', iff 9 unifies e\p (the subterm of e at position p) 

with the left-hand side I of some rule l=r (with fresh variables), and e' = 0(e[r]p) 
(where e[r\p is the result of replacing the subterm at position p of e by r). We will 
drop 0, p, or l=r from this notation when they are irrelevant. When presented, 
the representation of 9 will be restricted to the variables of a goal. 

As habitual in functional logic languages with a lazy operational semantics, 
we define the validity of an equation as a strict equality on terms denoted by 
the infix operator ==. Because of the applicative nature of our systems, strict 
equality is defined by the families of rules 

c == c = . , , Vc 

c Xi . . . Xn == cYi . . .Yn = Xi == Fi A . . . A A„ == F„, Vc, ar{c) ^ n > 0 
(Ai, . . . , A„) == (Ti, . . . , r„) = Ai == Ti A . . . A A„ == y„, Vn > 0 
/==/ = - , V/,ar(/)>0 

/ Ai . . . A„ == / Fi . . .r„ = Ai == Fi A . . . A A„ == V/,ar(/)>n ^ 0 

. AA = A 
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where c is a constructor and / is a function. (Recall that our language allows 
only partially-applied function symbols in a pattern.) 

A sequence of narrowing steps g'^e- , where TZ is the set of rules of p, is 

called an , , _ of (p, g) producing , _ 9. 

As a very simple example, consider the following problem, taken from [5, 
Ex. 1] (originally from [13]). 
z : nat 

s : nat -> nat 

twice (F:nat->nat) (X:nat) = F (F X) 

(G: (nat->nat)->(nat->nat) ) G s z == s (s z) 

A solution of this problem is the substitution {G i— > twice}. It is computed by 
the following evaluation. 

G S Z == S (s z) ^{GH^twlce} S (s z) == S (s z) trUG 

Note that we still haven’t suggested a strategy for choosing the appropriate se- 
quence of narrowing steps. In fact, while a great deal is known about efficient 
strategies for first-order programs, we understand much less about higher-order 
ones. We will show shortly, however, that typing information can be a valuable 
guide to computing an efficient strategy. The main idea of this paper is to re- 
duce the higher-order case to the first-order one while maintaining typability, as 
described in the next section. 

4 Translation 

The idea behind the translation is to encode all unapplied or partially-applied 
symbols^ as constructors (called ... .. . ), grouped into new alge- 
braic data types ( . , .. . . ), and replace all applications in the original pro- 
gram by applications of special new .. . ... _ ... As its name suggests, 

a dispatch function takes a closure constructor as argument, and, based on the 
value of that argument, dispatches control to (a translation of) the appropriate 
original function. The resulting program is well-typed in the strict first-order 
subset of the original language, so ordinary first-order narrowing strategies can 
be used to find solutions. 

The main novelty introduced by the presence of types is that the translation 
constructs type-specific dispatch functions and associated closure-constructor 
types, one for each different function type encountered in the source program. 
(The obvious alternative — using a single dispatch function that operates over 
all closure constructors — is unattractive, because such a function could not be 
given a conventional static polymorphic type; some form of dependent typing 
would be required, and this would in general require dynamic type checking.) 
The translation essentially consists of two parts: 

^ Because constructors in the source program can be treated just like first-class func- 
tions (e.g., as arguments to higher-order functions), they are encoded just like func- 
tions. 
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14 = d 








• ,tn)l = ([H] , . . . , It„l) 








^ t2] = $|t 




[deci . . . 


decm rulei . . . 


rule-nj = [deci] . . . [dec,yi] newsigs 








[rttZei] . . . [ritZen] newrules 








where newsigs = nsigs{deci) . 


. . nsigs{decm.) 






nsigs' {rulei) 


. . . nsigs' (rulen) 






and newrules = nrules{deci) . 


. . nrules{deCm) 






nrules {rulei) 


. . . nrules {rule-n) 


[(i>i 


, Vn ■ in') = 


= 62] = {vi : [tl] [tn]) [ei] = 


= bij 


[c 


• ^ ^ in 


, ^ d] = c : ([ti] ,. . . , [t„]) ^ d 


(if ar{c) = n > 0) 






= c d 


(if ar{c) = n = 0) 




If P 1 -. -Pn 


= e] = /(bil,...,bnl) = bi 




(patterns) 


l( 


V : t)j = {v : M) 






[(c Pi . 


■■p 4 ] = (c(biL---: b^il)) 








I/l = #/o 






[(/ Pi ■ 


■■Pn)} = (#/n(bll b"D) 








■ ,pn)} = (bib ■ ■ ■ . bril) 




(expressions) 


[n] = V 








0 

II 


(if ar{s) > 0) 






[s] = s 


(if ar{s) = 0 ) 




I(ei,.. 


-.e^)] = ([ei] ,...,Ie„l) 






[(ei 62)] ®|iypeo/(ei)| ’ I®^]) 





Fig. 3. Translation Rules. The notation for translation is overloaded to work on 
each syntactic class. The definitions of - y (),. - y. '(), . (), and , . '() are 

given in Figure 4. 



— generation of a set of new nullary or unary . . . , correspond- 

ing to partially applied functions and constructors in the source program, 
and a set of new unary ; 

— a syntax-directed transformation of the original program and goal, which re- 
places original constructor and function names by closure constructor names, 
original applications by dispatch function applications and original function 
definitions by equivalent uncurried function definitions. 

The closure constructors and dispatch functions are then integrated with the 
translated program to produce the complete translated problem. Details of the 
translation are specified in Figures 3 and 4. Borrowing from [.5] , we denote closure 
constructors with identifiers prefixed by “#,” closure types with the symbol 
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indexed by an (arrow) type, and dispatch functions with the symbol “0” indexed 
by a type. 



nsigs{s : ti 



nsigs{s : d) = {} 

#so : [ti 

^ tn ^ d) — < 



■■ [tl] ^ [t2 ^ . tn] , 



nsigs'if pi . . . p„ = e) = nsigs{f : typeof{f)) 



nrules{s : d) = {} 

: [ti]) = #si(ni), 

: [ti]),'C2 : [t2]) = 

nrules{s : ii tn —> d) = ^ #S 2 (vi, V 2 ), . . . , 

»t] (^3n—l(vi : [jil] , ■ . . , Vn — l • [tn — 1|, 
Vn : [tn]) = s(vi, . . .,V„) 

nrules {f pi . . . p„ = e) = nrules{f : typeof{f)) 



Fig. 4. Definition of closure constructors and dispatch functions. 



In a translated program, all functions appearing in expressions are fully ap- 
plied, so no applicative expression ever mentions a function. Thus, solutions of 
a goal under the translated program never mention the new .. . , . . functions, 
though they may mention the new #s constructors. Solutions may be trans- 
lated back into a higher-order form that doesn’t contain these constructors by 
translating each construction #sq into the symbol name s, and each construction 
#Sfc(ei, . . . , Cfc) into the application (s ei . . . e^). A complete inverse translation 
for expressions is given in Figure 5. 



4.1 Example 

Consider again the small example problem of the previous section. Our transla- 
tion gives the following target problem 
z : nat 

s : nat -> nat 
#twiceo : dl 
#twicei : d2 -> d2 
#So : d2 

twice (F:d2, X:nat) = @<12 (F,@d2 (F,X) ) 

@di (#twiceo :dl , F:d2) = #twicei(F) 

@d 2 (#twicei (F:d2) , X:nat) = twice (F,X) 

@d2(#so:d2, X:nat) = s(X) 

(G:dl) @d2(®di(G,#so) ,z) == @d2 (#so ,@d2 (#so ,z) ) 
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where 

= $lnat-.natl^|nat^natl = K^at -> nat) ^ (nat ^ nat)] 
d.2 ^|nat| — *|nat] Inat > natj 

An evaluation of the translated problem produces the following (incomplete) 
narrowing sequence: 



®d2 (®dl (Gr , #Sq) , z) 0^2 (#So , 0d2 (#Sq , z) ) 

'^{G^#twiceo} ®d 2 (#twicei(#So) ,z) == 0d2 (#Sq , @d 2 (#Sq , z) ) 
twice(#So,z) == 0d2(#So,@d2(#So,z)) 

'^{} ®d 2 (#So , 0d2 (#So , z) ) == 0d2 (#Sq , 0d2 (#So , z) ) 

The solution substitution {G #twiceo} to the translated problem is mapped 
by the inverse translation back to the substitution {G twice}, which is a 
solution of the original problem. 



|u]-i = V 
I#So]"| = s 

[#Sfc(ei, . . . , = (s ei . . . et) 

|c]~^ = c (for other constructors c) 

= ([ei],...,|[e„]) 

Fig. 5. Inverse Translation Rules. 



4.2 Discussion 

We have tried to present the translation in the simplest and most uniform way 
possible. As a result, the translated code is substantially more inefficient than 
necessary; this can be corrected by using a more sophisticated translation or 
by post-translation optimization, using standard simplification techniques. For 
example, we replace source applications by dispatch function applications, 
whereas in fact . applications whose operators are variables need to be dis- 
patched; when the operator is a known symbol, the dispatch function call could 
be inlined. As another example, translated functions are called in only one place, 
from within the (type-appropriate) dispatch function, so they could be inlined 
there without increasing code size. Note, however, that one cannot in general 
perform . .. these transformations simultaneously without risking a blow-up in 
the size of the translated program. 

Our translation relies fundamentally on having a monomorphic source pro- 
gram, so that each source function can be assigned unambiguously to a closure- 
constructor type and associated dispatch function in the target. It is obviously 
desirable to extend the translation to polymorphic problems. One straightfor- 
ward approach is to generate (automatically) multiple , - - . . versions of the 
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program’s polymorphic functions, one for each type at which the function is 
used, before applying the translation [12]. This method works for problems that 
combine polymorphic programs with monomorphic goals. For example, given the 
program 

u : f oo 
V : bar 
id (Z:a) = Z 

where a is a type variable, we can solve the goals 
(X:foo, Y:bar) (id X, id v) == (u,Y) 

(F:foo->foo,G:bar->bar) (F u, G v) == (u,v) 

by first specializing id into two functions 

id_foo (Z:foo) = Z 
id_bar (Z:bar) = Z 

and then translating to first-order and solving in the normal way. For the latter 
goal, we obtain the solution {F idJoo, G i— > id_bar}; we can transform both 
the monomorphic function names appearing in the solution back into id for 
presentation to the user. Note that the type annotations on variables F and G 
are needed to guide the specialization process. 

This approach fails to handle goals with polymorphic function-typed vari- 
ables. For example, given the above program, consider the goal 
(F u, F v) == (u,v) 

Here {F i— > id} is the (sole) solution to the polymorphic goal; no single monomor- 
phic instance can possibly be a solution. Solving this problem appears to require 
dynamic (runtime) type manipulation. For example, Hanus [8] has shown that a 
system using explicit type annotations on all terms together with runtime type 
unification can express the Warren transformation using a single polymorphic 
dispatch function; there are static analyses that permit the runtime types to 
be omitted, . . . there are no function- valued goal variables [7]. If there 

function-valued variables, some runtime type operations will need to remain, 
and it is not clear what level of static type checking can be guaranteed to the 
programmer; we are currently investigating this question. 

Our translation is presented as operating on an entire program at one time, 
but this is not a fundamental requirement. If the source program is given incre- 
mentally, the translation can be performed incrementally too, provided that it 
is possible to add new constructors to an existing algebraic datatype and new 
rules for an existing dispatch function on an incremental basis. 



5 Correctness 

In this section we formulate the correctness of our translation and sketch its 
proof. Intuitively, a translation of a source problem into a target problem is 
correct if solutions of the source problem can be computed by means of the 
target problem, i.e., if the following diagram commutes: 
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source translate target 

problem problem 



solve 



solve 



t 

solution 



inverse translate 



solution 



More specifically, it should make no difference whether we compute the so- 
lutions of a source program directly or through its translation. To formalize this 
idea, we need the following notation and definitions. If 0 is a substitution, we 
define |0] as the substitution that, for any variable v, |0] {v) = |6*(u)]. We say 
that a substitution 0 is . , - _ , if, for any variable v, 9{v) is an applicative 

term. Two substitutions are , .if each one can be obtained by the other 
through a renaming of variables. If 0 is a substitution and 5 is a goal, then 6>|y£,^(g) 
denotes the . - _ . of 0 to the variables of g. If P is a problem, then solve{P) 
is the set of its solutions. If ^ is a set, then [S'] = {|cc] \x S S}. The comparison 
of two sets of substitutions is always implicitly intended modulo equivalence of 
substitutions. 

Let P be a source problem. We say that a translation |] is . , . iff, for 

every source problem P, solve{P) C |soZue(|P])]~^. We say that a translation 
|] is iff, for every source problem P, solve(P) 3 |soZue(|P])]~^. 

Note that the soundness and completeness of a narrowing strategy used to 
compute a problem solution are not an issue for the soundness and completeness 
of a translation, though we envision that a sound and complete strategy will be 
used for the target program. 

We express the completeness of our translation as: 

. 6» . , _ , , . _ , , . . (t, 5 ) / - P 

- -4TRS . e' ■ 

w 

rirvU)-- ^ 

The proof of the completeness of our translation is in two parts. First, one proves 
the completeness claim when all the steps of a computation are rewriting steps by 
induction on the length of the computation. Then, one proves the completeness 
claim of a narrowing computation by lifting the completeness result for the 
corresponding rewrite computation. 

The intuition behind the completeness of our translation is that a compu- 
tation in the source program is “simulated” by a computation in the target 
program. For example, the evaluation presented in Section 4.1 simulates the 
corresponding evaluation presented in Section 3.4. 

Each application in the source program is replaced by at most two applica- 
tions in the target program (before optimization). Consequently, the derivation 
in the target program takes more steps than in the source program, but only by 
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a constant factor. Moreover, all the target program steps are first-order. In ad- 
dition, the optimized translation of a first-order source application is just itself. 
Thus, there is no loss of efficiency in the target program for purely first-order 
narrowing computations in the source program. 

We express the soundness of our translation as: 



The proof of the soundness of our translation stems directly from Gonzalez- 
Moreno’s work [5]. His translation of a problem can be obtained from our trans- 
lation of the same problem by collapsing all our dispatch functions into a single 
untyped dispatch function. Some consequences of this difference are discussed 
in Section 6. For example, his translation of Example 4.1 yields the following 
first-order program (where we have added type annotations): 
twice (F:nat->nat, X:nat) = @(F,@(F,X)) 

@(#twiceo : (nat->nat)->(nat->nat) , F:nat->nat) = #twicei(F) 

@(#twicei (F:nat->nat) , X:nat) = twice(F,X) 

@(#so :nat->nat , X:nat) = s(X) 

(G: (nat->nat)-> (nat->nat) ) @(@(G,#so) ,z) == @(#so ,@(#So ,z) ) 

Therefore, every solution (substitution) of a problem computed via our trans- 
lation is also computed by Gonzalez-Moreno’s translation of the same problem. 
Thus, [5, Th. 1] directly implies that our translation is sound. 



The benefits of our approach to higher-order narrowing computations can be 
better understood by comparing it with related work. 

6.1 Smaller Narrowing Space 

The approach to higher-order narrowing closest to ours is [5]. The major dif- 
ference between these approaches is that our target programs are well-typed 
whereas the target programs in [5] are not. We show the effects of this difference 
on the narrowing space of the example discussed in Section 5. Figure 6 shows a 
portion of the goal’s narrowing space computed with the translation proposed 
in [5], where 2 is an abbreviation of s {s z). The same portion of narrowing space 
generated by our target program contains only the left branch. Both middle and 
right branches of Figure 6 contain ill-typed terms. The right branch is infinite 
due to 



@(G,#so) @(GG(§(GG#so)) @(G’ ’@(G’ G@(G’ G#sq))) . 
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6 Related Work 



These conditions, neither of which arises with our translation, have far reaching 
consequences. An increase in the branching factor of the nodes of a narrowing 
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@(@(G,#so) ,z)==2 




®(@(G’ ,@(G’ ,#so)) ,z)==2 



Fig. 6. Portion of the search space of @(@(G,#So) ,z)==2 



space implies an exponential growth of the number of nodes that may be gen- 
erated during a computation. The presence of infinite branches in the search 
space implies that sequential implementations of complete narrowing strategies 
may become operationally incomplete. Even if these extreme consequences can 
be avoided in many cases, we expect in most cases a substantial slowdown of 
narrowing computations that discard type information. This observation is also 
made in [10]. 

Of course, even branches containing only type-correct terms may be infinite, 
making the use of sequential implementations problematic. We believe, however, 
that the behavior of such implementations will be much easier for the program- 
mer to understand if they are guaranteed to proceed in a well-typed manner. 
Gratuitous alteration of the size or finiteness of the narrowing space which can- 
not aid in finding solutions is surely unacceptable. 

6.2 Expanded Programs 

Our overall approach has a significant difference with respect to both [6,10]. 
We reduce higher-order narrowing computations to first-order ones by means of 
a program translation that is largely independent of both the class of source 
programs and the narrowing strategy applied to these programs. This decou- 
pling opens new possibilities. For example, there is no published work on higher- 
order narrowing in both constructor based, weakly orthogonal rewrite systems 
and inductively sequential, overlapping rewrite systems. It is easy to verify that 
our translation preserves many common properties of rewrite systems, includ- 
ing weak orthogonality and inductive sequentiality. Since sound, complete, and 
efficient first-order narrowing strategies are known for both weakly orthogonal 
rewrite systems [2] and inductively sequential, overlapping rewrite systems [1], 
our approach immediately provides a means for higher-order narrowing compu- 
tations in these classes. 
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6.3 Efficiency 

Another difference of our approach with respect to both [6,10] is the granularity 
of the steps. Both [6,10] perform narrowing computations by means of inferences 
whereas our approach promotes the use of strategies that perform true narrowing 
steps. Generally, we expect an overhead when a narrowing step is broken into 
many inferences. 

A noteworthy feature of our approach is that when no variable of function 
type is instantiated, higher-order narrowing computations do not cost signifi- 
cantly more than first-order narrowing computations. This feature is essential 
for powerful functional logic languages. For example, the current proposal for 
Curry defines the dispatch function as - y- - , thus excluding higher-order narrow- 
ing computations from the language, “since higher-order unification is an expen- 
sive operation” [4, Sect 2.6]. Our translation is a step toward lifting exclusions of 
this kind. Indeed, the above feature extends (at least for monomorphically typed 
programs) the behavior of modern narrowing strategies in that when no variable 
is instantiated, narrowing computations should not cost significantly more than 
functional computations. 

6.4 Partial Applications in Patterns 

There is a significant difference between [6] and the other higher-order narrowing 
approaches referenced in this paper. In [6], the patterns of a rule may consist of 
or contain higher-order patterns [9]. For example, [6, Ex. 1.2] defines a higher- 
order function , where - {F, X) computes the differential of E at A in the 

form of a higher-order pattern. The rules of - include higher-order patterns 
for symbols such as sin, cos, and In. Although intuitively these symbols stand 
for functions sine, cosine, and logarithm, the program defines neither the sym- 
bols nor the functions by means of rewrite rules. Our approach supports and 
extends this feature. The following definitions, where for readability we omit 
type declarations, allow us to express polynomial functions. 

const N _ = N 
X X = X 

plus FGX=FX+GX 
times FGX=FX*GX 

For example, the function + 1 would be expressed using the above rules as 
plus (times x x) (const 1) 

The following program defines our function. Similar to [6], narrowing allows 
us to use - to compute symbolic integration, although alone would be 
inadequate in most cases. By contrast to [6], we use - to compute both the 
symbolic derivative with respect to a; of a polynomial and the differential of a 
polynomial &t x = X — in our framework the former evaluates to a function 
and the latter evaluates to a number, 
diff (const _) = const 0 
diff X = const 1 
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diff (plus F G) = plus (diff F) (diff G) 

diff (times F G) = plus (times (diff F) G) (times F (diff G) ) 

For example 

plus (times x x) (const 1) 2 5 

diff (plus (times x x) (const 1)) 2 4 

diff (plus (times x x) (const 1)) 

plus (plus (times (const 1) x) (times x (const 1))) 

(const 0) 

A “simplification” function with rules such as the following ones would be useful 
to improve the latter and necessary to compute non-trivial symbolic integration. 

simpl (plus F (const 0)) = F 
simpl (times F (const 1)) = F 

Our approach eases understanding the appropriateness of this unusual program- 
ming style. Intuitively, both functions and constructors of the source program 
become (closure) constructors of the target program, hence function symbols in 
patterns of the source program need not be harmful. Indeed, higher-order pro- 
gramming is, loosely speaking, allowing a function / to be the argument of a 
function g. A rule of g has generally a variable, of functional type, to match or 
unify with /, but there is no reason preventing the use of the symbol / itself 
in the rule of g. Furthermore, since we do not allow fully applied functions in 
patterns, the use of functions in patterns does not compromise the confluence 
of the program, although the lack of confluence would not be an issue for our 
translation in any case. 



7 Conclusion 



We have presented a translation from source to target programs that allows 
us to perform higher-order narrowing computations with first-order narrowing 
strategies. This has several noteworthy advantages. 

Our approach immediately provides sound, complete and efficient higher- 
order narrowing computations for large classes of systems for which no sound, 
complete and/or efficient higher-order narrowing strategies were known. 

Our approach refines previous translation attempts by preserving in the tar- 
get program type information of the source program. It is easy to verify that 
even in trivial examples this has a dramatic effect on the size of the narrowing 
space. 

Our approach allows and justifies the presence of function symbols in the 
patterns of a rewrite rule. This feature extends the use of higher-order patterns, 
increases the expressive power of a language and simplifies metaprogramming 
tasks. 
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Abstract. We introduce a denotational characterization of narrowing, 
the computational engine of many functional logic languages. We use a 
functional domain for giving a denotation to the narrowing space associ- 
ated to a given initial expression under an arbitrary narrowing strategy. 
Such a semantic description highlights (and favours) the operational no- 
tion of evaluation instead of the more usual model-theoretic notion of 
interpretation as the basis for the semantic description. The motivation 
is to obtain an abstract semantics which encodes information about the 
real operational framework used by a given (narrowing-based) functional 
logic language. Our aim is to provide a general, suitable, and accurate 
framework for the analysis of functional logic programs. 

Keywords: domain theory, functional logic languages, narrowing, pro- 
gram analysis, semantics. 



1 Introduction 

The ability of reasoning about program properties is essential in software design, 
implementations, and program manipulation. Program analysis is the task of 
producing (usually approximated) information about a program without actually 
executing it. The analysis of functional logic programs is one of the most challeng- 
ing problems in declarative programming. Many works have already addressed 
the analysis of certain run-time properties of programs (e.g., [3,11,13,15,23]). 
Nevertheless, most of these approaches have been done in a rather ad hoc set- 
ting, gearing the analysis towards the application on hand. Up to now, there is 
no general approach for formulating and analyzing arbitrary properties of func- 
tional logic programs in an arbitrary operational framework. In this paper we 
address this problem. 

The key of our approach is domain theory [19,20] since it provides a junction 
between semantics (spaces of points = denotations of , . _ ) 
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and logics (lattices of properties of processes) [2,20,22]. The computational pro- 
cess we are interested in is evaluation. In a programming language, the notion of 
emphasizes the idea that there exists a distinguished set of syntactic 
elements (the values) which have a predefined mathematical interpretation [10]. 
The other syntactic elements take meaning from the program definitions . . the 
operational framework for the program’s execution. In this way, the evaluation 
process (under a given operational framework) maps general input expressions 
(having an , . . unknown meaning) to values. This point of view favours 

the operational notion of evaluation instead of the more usual model-theoretic 
notion of interpretation as the basis for the semantic description. 

Since functional logic languages with a complete operational semantics are 
based on narrowing, we center our attention on it. The idea of using narrowing as 
an , , _ , . . for integrated languages comes from Reddy’s [18]: nar- 
rowing is the operational principle which computes the > , . , ( > ) 

of an input expression. Given a domain D, a, ^ is a , , - y from valuations 

(on D) to values (in D) . In moving valuations from being parameters of seman- 
tic functions (as usual in many approaches, e.g., [9,16]) to be components of a 
semantic domain, we understand narrowing as an , , _ . mechanism which 

incorporates the instantiation of variables as a part of such evaluation mecha- 
nism. Since . y ’s are functional values, we use the domain-theoretic notion of 
- . y [19,20] to give them a computable representation. We ar- 

gue that this is a good starting point for expressing and managing . . 
properties of functional logic programs (along the lines of [2,22]). Moreover, it 
reveals that, within an integrated framework, there exist semantic connections 
between purely functional and logic properties of programs. Termination and 
groundness are examples of such related properties. On the other hand, thanks 
to including operational information into the semantic description, we are able 
to derive interesting optimizations for program execution. 

Section 2 gives some preliminary definitions. Section 3 introduces a domain 
theoretic approach to pure rewriting and narrowing computations. Section 4 
discusses a semantic-based analysis framework for functional logic languages. 
Section 5 contains our conclusions. 

2 Preliminaries 

In this section, we give some preliminary definitions (further details in [6,21]). 
Given sets A, B, is the set of mappings from A to B and V{A) denotes 
the set of all subsets of A. An . C on a set A is a reflexive, transitive and 
antisymmetric relation. An element T of an ordered set (A, C) is called a 

. (or a , ) if T G a for all a G A. If such an element exists, then 

(A, G,T) is called a. - . . . . .. Given S' C A, an element a G A is an 

. of S if a: G a for all a; G S. In this case we also say that S is a 

- . . . . An upper bound of S is a (or , , , written jj S) 

if, for all upper bounds b of S, we have jJ S G 6. A set S C A is downward 
(upward) closed if whenever a G S and 6 G a (a G 6), we have that 6 G S. If 
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S = {x, y}, we write xUy instead of (J S'. A non-empty set S C A is .. . . if, 

for all a,b € S, there is an upper bound c G S of {a, b}. An ideal is a downward 
closed, directed set and . (A) is the set of ideals of an ordered set A. A pointed 
ordered set (A, C, _L) is a , , . , _ . ( , ) if every directed set S C A 

has a , . y S G A. An element a G A of a , is called , , . (or . . ) if, 

whenever S C A is a directed set and a C |J S, then there is cc G S such that 
a C X. The set of compact elements of a cpo A is denoted as K{A). A cpo A is 
^ . if for each a G A, the set approx(a) = {x G K{A) | x Cl a} is directed 

and a = |Japprox(a). An algebraic cpo I? is a . , - if, whenever the set 

{x, y} C K{D) is consistent, then xUy exists in D. Given ordered sets (A, Ea), 
(B, Es), a function f : A ^ B is monotonic if Va, b G A, a Ea b ^ f(a) Es f(b)', 
/ : A ^ A is idempotent if Va G A, /(/(a)) = /(a). 

By V we denote a countable set of , - , ; A denotes a, . , .. , i.e., a 

set of,, - . {f,g,...}, each with a fixed given by a function 

ar : A —> IN. We assume A n A = 0. We denote by T(A, V) the set of (finite) 
terms built from symbols in the signature A and variables in A. A /c-tuple 
ti, . . . ,tk of terms is denoted as t, where k will be clarified from the context. 
Given a term t, Var(t) is the set of variable symbols in t. Sometimes, we consider 
a fresh constant _L and Aj_ = AU {A}. Terms from T(Aj_,A) are ordered by 
the usual , , - _ . - ^ which is the least ordering E satisfying T E i 

for all t and f(t) E /(s) if t E 5, i.e., E E Si for all 1 < i < ar{f). 

Terms are viewed as labeled trees in the usual way. - _ p,q, . . . are 
represented by chains of positive natural numbers used to address subterms of 
t. By A, we denote the empty chain. The set of positions of a term t is denoted 
by Vos{t). A . . , is a term having no multiple occurrences of the same 

variable. The subterm of t at position p is denoted by t|p. The set of positions of 
non- variable symbols in t is Voss{t), and Vosv{t) is the set of variable positions. 
We denote by t[s]p the term t with the subterm at the position p replaced by s. 

A , . _ _ is a mapping a : A ^ T(A,A) which homomorphically ex- 
tends to a mapping cr : T(A,A) — > T(A,A). We denote by £ the “identity” 
substitution: £r(x) = x for all x G A. The set Vom{(j) = {x G A | ct(x) yf x} 
is called the . - of cr and TZng{a) = Ax^vom{cr)Var{a{x)) its ^ . a\jj de- 

notes the . - - of a substitution ct to a subset of variables U C Vom{(j). 
We write a < a' ii there is 9 such that a' = 6 o a. A . . of two terms ti,t 2 
is a substitution CT with cr(ti) = CT(t 2 )- A , . ( ^, ) of G, ^2 is a 

unifier ct with a < o' for all other unifiers o' of 

A / (labeled a) is an ordered pair (l,r), written a : I — > r (or 

just I r), with l,r G T(A, A), I ^ A and Var(r) C Var{l). I and r are 
called (. ) and ( . ) of the rule, respectively. 

A . / — , - . ( ) is a pair 7?. = (A, i?) where i? is a set of rewrite 

rules. A TRS (A, i?) is - , if for all I ^ r G i?, ? is a linear term. 

Given TZ = (A, i?), we consider A as the disjoint union A = C l±l IF of symbols 



c G C, called . , . , and symbols / G A, called . . - , where 

A = {/ I /(I) ^ r G i?} and C = A - A. A . , . . . TRS ( ) is 



a TRS with E, ■ • ■ Jn G T{C, A) for all rules /(E, ■ • . ,ln) ^ r. 
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For a given TRS TZ = {S, i?), a term t ^ . to a term s (at position p), 

[p,Ck!] p 

written A 7^ (or just t s, t —>7^ s, or t ^ s) if t|p = cr(Z) and s = t[a(r)]p, for 
some rule a : I —f r G R, position p G Vosit) and substitution a. A term t is in 
if there is no term s with t s. A TRS TZ (or the rewrite relation 

— >7^) is called if for all terms t, ^1,^2 with t ti and t — t2, there 

exists a term with ti — and t2 — A term t / to a term s, 
written t '^[p^a,a] s (or just t s), if there is p G Voss{t) and a variant (i.e., a 
renamed version) of a rule a : Z — > r such that t\p and I unify with (idempotent) 
mgu a, and s = a{t[r]p). A narrowing derivation t s is such that either t = s 
and tr = £T or t ■ ■ • tn-i s and a = cr„_io- • -ocriocro- In order 

to show the progress of a narrowing derivation w.r.t. the computed answer and 
the evaluated goal, we also define the narrowing relation on substitution/term 
pairs by (tr, t) {a' , s) if t '^g s and a' = 0|var(t) ° cr (i.e., we consider only the 
substitution of goal variables). 

3 The Semantic Approach 

A (first-order) program V = {TZ, t) consists of a TRS TZ (which establishes the 
distinction between constructor and defined symbols of the program), and an 
initial expression t to be,, . evaluated. We make t explicit since the differences 
between the purely functional and functional logic styles arise in the different 
status of the variables occurring in the initial expression: in functional program- 
ming, those variables are not allowed (or they are considered as constants and 
cannot be instantiated) . Functional logic languages deal with expressions having 
y. variables and narrowing provides for the necessary instantiations. 

We characterize the information which is , ... couched by a term by 

means of a mapping ( ) from terms to (partial) values (remind that values are 
expected to be especial syntactic objects). We call ( |) an . , . _ . mapping. 

The adequacy of a given mapping ( [) for observing computations performed 
by a given operational mechanism should be ensured by showing that (] ) is a 
homomorphism between the relation among syntactic objects induced by the 
operational mechanism and the approximation ordering on values. This means 
that the operational mechanism refines the meaning of an expression as the 
computation continues. 

As a preliminary, simple example, consider pure rewriting computations: 
The syntactic objects are terms t G T{S±,V) and the values are taken from 
(T°°(Cj_), C, T), the domain of infinite, ground constructor (partial) terms^. 
(T°°(Cj_, V), C, T) is the domain (T°°(Cj_ U V),\G, T), where Vx G V, ar{x) = 0. 
For functional computations, we use (] : '^{^±, V) — > T(Cj_, V) given by 

(]x|)f = X _ (T|)f = -L 

(c(t)|)F = c(P)f) if cGC (/(t))F = A iifGR 



^ Formally, (T°°(Cj_), T) is obtained from T{C±), which is not even a cpo, as (iso- 
morphic to) its ideal completion (H(T(Cx)), C, {T}) (see [21]). 
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Proposition 1 (Reduction increases information). .72. 

The function Rew : T{E_\_,V) V{T{C_l,V)) gives a representation Rew{t) = 

{(|s|)f I t s} of the rewriting space of a given term t. 

Proposition 2. . 72 , t G T{Ejl,V) Rew(t).. 



The semantic function CRew°° : V) — > T°°{C_\_,V) gives the meaning of 

a term under evaluation by rewriting: CRew°°{t) = [J Rew{t). Thus, CRew°°{t) 
is the most defined (possibly infinite) value which can be obtained (or approx- 
imated) by issuing rewritings from t. Note that the use of infinite terms in the 
codomain of CRew°° is necessary for dealing with non-terminating programs. 

3.1 Narrowing as the Evaluation Mechanism 

In the context of a program, a term t with variables denotes a continuous function 
to & \D^ ^ D] which yields the evaluation of t under each possible valuation^ 
4> € of its variables on a domain D. This is called a > , . , ( > ) 

in [18] and a . - . . , . in [8]. 

Given domains D and E, the set \D E] of (strict) continuous functions 
from D to E (pointwise) ordered by / C g iff Vcc S V, f{x) G g{x)^ is a domain 
[10,21]. For proving that \D^ — > 77] is a domain whenever D is, assume that 
V contains a distinguished (unused) variable T. Thus, V supplied by the least 
ordering C such that E E x and a: C a: for all cc € E is a domain. The set 
]jy-{x} arbitrary valuations from V — {T} to D is isomorphic to the domain 
[V ^_L D] of continuous, strict valuations. We assume this fact from now on by 
removing T from V and considering that is a domain. Therefore, [D'^ — *■ D] 
is a domain and, in particular, [T°°(Cj_)^ ^ T°°{C±_)] also is. 

Our syntactic objects, now, are substitution/term pairs (cr, 7). We could 
naively extend (] )f to deal with those pairs: (](cr,s)])F = ((]o’[)f, (]s])f) where 
(]cr[)F is a substitution given by (]cr[)F(a;) = (]cr(x)[)F for all x & V. Unfortunately, 
the semantic progress of a narrowing evaluation might not be captured by the 
computational ordering C (extended by {4>,S) U iff Va: € V.(p{x) tZ 4>'{x) 

and 6 G S ') and such an extension of (] ])f. 

Consider the TRS 

0+x — *■ X 0 < X — > true 

s(x)+y — > s(x+y) s(x) < s(y) — *■ x < y 

and the narrowing step {e, [x,x+y]) ({xi— >0}, [0,y]) ([•,•] denotes a 2- 

element list). We have ((e, [x,x+y])])F = (e, [x,T]) and (]({xi-^0}, [0,y])j)F = 
({xi— >0}, [0,y]). Therefore, we do not get the desired increasing computation, 
because e: % {xi— >0} and [x,T] % [0,y]. 



^ By abuse, we say that the ‘domain’ of a valuation 4> £ is 'Dom{(j)) = {x £ 
V I S>{x)^E}. 
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The problem is that narrowing introduces a new computational mechanism for 
increasing the information associated to a given term, i.e., instantiation of . y- 
variables. Thus, we introduce the observation mapping (] Dfl : ^ 

T(Cx) which interprets uninstantiated variables as least defined elements: 

= T ^ dJ-|)-FL = -L 

dc(t)|)FL = c(dt|)Fi) if C e C (\f{t)\)FL = T if f € T 

Note that d^DFL = Tsubsi(d^DF) and d^DFi = -Lsubst o dcr|)F. 

Now, d(e, [x,x+y])[)Fi = [T,T]) C ({xi->0}, [0,T]) = 

d({xi— >0}, [0,y])DFL, i.e., d Off satisfies the desired property. 

Narrowing computations are compatible with the new observation mapping. 

Proposition 3. . n . y (cr',s) .. . (\{a,t)\)FL E 

d(cr',s)DFL 

3.2 The Narrowing Space as an Approximable Mapping 

Analogously to Rew{t), we can build a semantic description Narr{t) of the 
narrowing evaluation of t. Nevertheless, since Narr(t) is intended to be a rep- 
resentation of a y, , i.e., a,, _ value, we need to use the corresponding 

standard Scott’s construction of , . y [20,21]. 

A . is a structure P = (P, Q, U, T) where C is a preorder, T is a 

distinguished minimal element, and U is a partial binary operation on P such 
that, for all a, b G P, a Li b is defined if and only if {a, b} is consistent in P 
and then a U 6 is a (distinguished) supremum of a and b [21]. Approximable 
mappings allow us to represent arbitrary continuous mappings between domains 
on the representations of those domains (their compact elements) as relations 
between approximations of a given argument and approximations of its value at 
that argument [21]. 

Definition 1. [21] . P = (P, C, U, T), P' = (P', C', U', T') . .. 

- - / C P X PP , , ^ y , P - P'.. 

T / T' 

a f b - a f b' . , . a f {bUb') 
a f b a' ^ b' b. , a' f b' 

The ideal completion ( _ (P),C,{T}) of a precusl is a domain (see [21]). An 
approximable mapping defines a continuous function between _ (P) and _ (P^- 
/ : - (P) — *■ - (P') is given by /(/) = {6 G P' | 3a G / with a f b}. 

Proposition 4. . P = (P, C, U, T), P' = (P', C', U', T') 

fJ'CPxP'. .. . ^ P P' , fcf .. JnJ 

Given a term t, - , (t) is the set of narrowing derivations issued from t. We 
associate an approximable mapping Narr^(t) to a given narrowing derivation 
Ag (t). 
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Definition 2. . . t € T(17 _l, V) , . _ 

A : {e, t) = (do, to) (di, tl) (cr„_l, t„_l) {dn,tn) 

y _ Narr^{t) =Uo<i<nNarrf{t) j . 

Narrf{t) = {{,,S) \ 3^GT{C^f.Uo di\)FL E A (5 C (|</>(E)Dfl} 

Proposition 5. . TZ , t , . - A , y _ . _ 

. - y y - t . . Narr^{t) - , . , - y 

Definition 3. - . . t G T(I7x,E) ^ . Narr{t) C 

T(Cx)^ X T(Cx) - , Narr{t) = Uy4eATDe™(t) NarT^{t) 

Unfortunately, these semantic definitions are not consistent w.r.t. rewriting. 

Consider the TRS 
f(f(x)) — *■ a 
c — > b 

and A : {e,t) = (e, f(x)) -Ny}- ({x f(x’)},a). If m = Narr^{t)^ then {x i— *■ 

a} TO a (we take 4> = 3-Subst, cr = {x i—> f (x’ )} in Definition 2; hence, (\(j)o d\)pL 
= -Lsubst E {x a} = <r). Thus, Narr^(t)({x a}) = a. However, {x i— > 
a}(t) = f (a) a. 

The problem here is that ( [)fl identifies (as T) parts of the bindings d(x) of a 
computed substitution d which can be semantically refined by instantiation (of 
the variables in cr(a;)) and other which cannot be further refined by instantiation 
(the operation-rooted subterms in d(x)). If we deal with left-linear CB-TRS’s 
and choose (idempotent) mgu’s as unifiers for the narrowing process, the sub- 
stitutions which we deal with are constructor substitutions, i.e., for all 

narrowing derivations (e, t) {d, s) and all x G V, d(x) is a constructor term 
and {d{x) I X G T>om{d)} is a linear set of terms (i.e., no variable appears 
twice within them). Hence, the substitutions computed by narrowing have 
partial information apart from the variable occurrences. In this case, = d, 

dcr|)FL = Tsubst o dcr);^ = ° d, and we have the following result. 



Proposition 6. . tr , - . . . . , .. . </>, G T(C±)^ 

, (f> o d g .. .. ... (j)' gT (Cx ■ ■ ■■ ■ 'a 4>' - <t>' o d = g 



Thus, we obtain a simpler, more readable expression for the approximable map- 
ping which is associated to a given left-linear CB-TRS by noting that 

Narrf{t) = {{g,S) \ 3(j) G 'T{C±)'^ .(\4> ° <^i\)pL E A 5 E d</'(E)DFi} 

= {(<?, 5) I 3<l) G T{C±)^ .(j)o di = A (5 E (\4>(ti)\)FL} 

The union of approximable mappings (considered as binary relations) need not 
to be an approximable mapping. Nevertheless, we have the following result. 
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Proposition 7. .72, , . - . 7 , . 

Narr{t) , . , - y 

We define the semantic function CNarr°° : V) — > \T°°{C±)^ — > T°°{C±)\ 

as follows: CNarr°°{t) = Narr{t), i.e., CNarr°°{t) is the continuous mapping 
associated to the approximable mapping Narrit) which represents the narrowing 
derivations starting from t. This semantics is consistent w.r.t. rewriting. 

Theorem 1. . 72, . - 7 S T(I7 _l,F) 

4> e CNarr^it) = C Rew°° 

Narrowing strategies. A narrowing strategy Af is a restriction on the set of 
possible narrowing steps. Given a narrowing strategy Af and a term 7, we can 
consider the set - Q - (t) of derivations which start from 7 and 

conform to Af. By Proposition 5, each A G . defines an approximable 

mapping Narr^{t) which is obviously contained in Narr{t). By Proposition 4, 
Narr^{t) C Narr{t) = CNarr°°{t). Therefore, {Narr^{t) \ A G - A7(7)} 
is bounded by CNarr°°{t). Since ^ T°°{C±)] is a domain, it is con- 

sistently complete, i.e., the , . of every bounded subset actually exists (Theorem 
3.1.10 in [21]). Thus, for left-linear CB-TRSs, we fix 

CNarr^{t) = |J{iVarr^(7) | A G - . a7(7)} 

to be the meaning of 7 when it is evaluated under the narrowing strategy Af . 
Clearly, for all narrowing strategies Af, CNarr^ C CNarr°° . Thus, CNarr°° 
provides a semantic reference for narrowing strategies. Strategies that satisfy 
CNarr^ = CNarr°° can be thought of as correct strategies. 

Narrowing is able to yield .. y , . of a function / by computing 
CNarr°°(f{x)), where xi,... ,Xar(f) are different variables. This gives an in- 
teresting perspective of narrowing as an operational mechanism which computes 
denotations of, , _ . . as a whole, rather than only values of particular function 

calls. A similar observation can be made for narrowing strategies. 



3.3 Computational Interpretation of the Semantic Descriptions 

Our semantic descriptions are intended to provide a clear computational inter- 
pretation of the semantic information. This is essential for defining accurate 
analyses by using the semantic description. 

Propositions. .72. t G T{E±,V) . S = CRew°°{t) 

. S G T{C,V) .. . t^* 6 

Concerning narrowing computations, we have the following result. 

Proposition 9. . 72, , - . . . 7 , . 

<; € T(Cx)'^ m = CNarr°°{t) . 6 = m{<;) 
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, S € T{c±) .. 4- 4 -■ - {e,t) {a,s) . .. . 

(j)oa = (; . - S = (|(;()(s)Dfl 

4-4 - - {e,t) {a, s) . .. .4>oa = <;-.- 

d<i!'(s)DFL E S 

,SeT{C).. .. - (e, t) (cr, s) . , . 

.. . s G T {C , V) (j)o a = c, _ 5 = (j){s) 

We are able to refine the computational information couched by the narrowing 
semantics by introducing a small modification on it. 

Definition 4. . . t G V) 4- 4 - - . - 

A : {e, t) = (ao,to) (ai, ti) (cr„_i, t„_i) (an,tn) 

4 - BNarr^(t) = Uo<i<n^^arrf(t)4- 

BNarrf(t) = {((^,S) | dciDFL E ? A 5 C (|E[)fl} 



Proposition 10. . 7Z . t , . - A , 4 - _ 4 - - - - 

■ - 4 .- t . . BNarr^{t)- > 

If we define BNarr{t) = UAGJVFe™(t) BNarr^{t), we have the following result. 

Proposition 11. . TZ , - t , . 

BNarrit) - , . , - y 



The basic description BNarr°°{t) = BNarr{t) is closer to the computational 
mechanism of narrowing. The following proposition formalizes this claim. 



Proposition 12. 


n . 


^4. ~ 


.... 


t . - 


T(C_l)^ m = BNarr 


~(t) 


. <5 = 


m(<j) 




4 5 G T(Cx) - 

(j)o a = (; . . S = 


ds[)FL 




4^ 4 - - - 


(e,t) (cr,s) , . 


ds[>FL E <5 






(e,f) (cr,s) 


- - - (\cr\)FL E 


Proposition 13. 


n . 






t . 


m = BNarr°°(t) , ( 


e,t) 


(cr, 6) 


. _ (5 e T(C) .. 


m{(\a\)FL) = S 



Since each BNarrf{t) is a special case of Narrf{t), by Proposition 11 and 
Proposition 4, BNarr°°{t) C CNarr°°{t). 
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4 A Semantics-Based Analysis Framework 

Domain theory provides a framework for formulating properties of programs and 
discussing about them [2,20]: A property tt of a program V whose denotation 
\P\ is taken from a domain D (i.e., \P\ G D) can be identified with a predicate 
7T : D — > 2, where 2 is the two point domain 2 = {_L,T} ordered by _L C T 
(where _L can be thought of as false and T as true). A program V satisfies tt 
if Tr(|7^]) = T (alternatively, if \P\ G 7r“^(T)). As usual in domain theory, we 

require continuity of tt for achieving computability (or , , , see [22]). 

The set [D 2] of observable properties is (isomorphic to) the family of open 
sets of the .. . . y. associated to D [2]. A . . y. is a pair (A, r) where 

A is a set and r C V{X) is a family of subsets of A (called the . , sets) such 
that [21]: A, 0 G r; if f7, F G r, then t/ n F G r; and if G r for i G /, then 
UiG/ ^ Scott’s topology associated to a domain D is given by the set 

of upward closed subsets U C D such that, whenever A C D is directed and 
jj A G f7, then 3x G A.x G U [21]. 

The family r of open sets of a given topology (A, r) ordered by inclusion is a 
. The top element of the lattice is A. Note that, when considering 
the Scott’s topology (D, tjj) of a domain D, the open set D denotes a trivial 
property which every program satisfies; 0, the least element of lattice td, denotes 
the ‘impossible’ property, which no program satisfies. 



4.1 Analysis of Functional Logic Programs 

A program analysis consists in the definition of a continuous function a : D — > A 
between topologic spaces {D,td) and (A,ta) which expresses concrete and ab- 
stract properties, respectively. By the topological definition of continuity, each 
open set V G ta maps to an open set U G Tjy via i.e., a~^ : ta ^ ru is a 
mapping from abstract properties (open sets of ta) to concrete properties (open 
sets of td)- It is easy to see that (D, {a“^(F) ] V G ta}) is a subtopology of D 
(i.e., {a~^{V) 1 V G ta} C td)- Therefore, each analysis distinguishes a subset 
of properties of D which is itself a topology. For instance, the Scott’s topology 
of 2 is given by t -2 = {0,{T},2}. Such a topology permits to express only one 
non-trivial property, namely, the one which corresponds to the open set {T}. 

In functional logic languages, the semantic domain under observation is 
[D^ — > D], Observable properties of functional logic programs are open sets 
of its Scott’s topology. Approximations to such properties can be obtained by 
abstracting \D'^ D] into a suitable abstract domain (see below). 

Every continuous function f : D ^ E maps observable properties of the 
codomain E into observable properties of D (by : te — > te)- In particular, 
elements of [D^ — s- D], i.e., denotations of functional logic programs, map prop- 
erties of D (we call them ‘functional’ properties) into properties of (‘logic’ 
properties). This provides an additional, interesting analytic perspective: By 
rephrasing Dybjer [7], we can computationally interpret this correspondence as 
establishing the extent that a ‘logic property’ (concerning valuations) needs to be 
ensured to guarantee a property of its functional part (computed value). There 
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is a simple way to obtain an abstraction of the logic part of \D^ — > D] from 
an abstraction of its functional part D. 

Definition 5. . D,V, A ap : D ^ A , , , - ^ ■ ctL ■ 

A^ . aLifj)) = apofj) . </> € 

. - , - - Ctp 

li ap ■ D ^ A IS strict (surjective, continuous), then ap is strict (surjective, 

continuous). Whenever of is a . mapping from a domain D to 2, ap 

expresses, in fact, a single observable property a“^({T}) of D. We can thought 
of OF as a,, - property. Thus, Definition 5 associates an abstraction ap of 

to a given property identified by of. Thus, each functional property induces 
a related . of logic properties which is a , , . , > . of r^v. In Section 4.3 we 

show that groundness (a logic property), is induced by the functional property 
of termination. 

4.2 Approximation of Functions 

Abstractions ap : D ^ A and ap ■ E ^ B {A and B being algebraic lattices), 
induce . , and - , . abstractions c^d^e ■ {D ^ E) ^ {A ^ B), of 

continuous mappings by [1] 

ap^p{f){d) = U{(oF o /)(d') I aoid') C d}, and 
aD^pU){d) = n{(oF o f){d') I aoid') □ d} 

where the following correctness result holds: 

Theorem 2 (The semi- homomorphism property [1]). . f ■. D ^ E 

= o:f)^pif) - oap Qapo f r fS oap 

Consider an abstraction ap : E ^ 2 which can be thought of as a , , .. of 

elements of the codomain E of f : D ^ E. For analytic purposes, the correctness 
condition /'® o ap 3 ctp ° / ensures that, for all x £ D, whenever the abstract 
computation /^{apix)) yields T, the concrete computation f{x) does . sat- 
isfy the property ap, i.e., ap{f{x)) = T. On the other hand, the correctness 
condition o ap ^ ap o f ensures that, whenever f^{ap{x)) yields T, the 
concrete computation f{x) actually satisfies ap, i.e., ap{f{x)) = T. We use this 
computational interpretation later. 



4.3 Termination Analysis and Groundness Analysis 



The functional structure of the semantic domain of . y, ’s reveals connections 
between apparently unrelated analyses. Consider ht : T°°{C±) — > 2 defined by 



ht{S) 



T if <5 e T(C) 
T otherwise 



and let hg : T°°(Cj_)^ 2'^ be the logic abstraction induced by ht- Note that 

both ht and hg are strict and continuous. Abstractions ht and hg express the 
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observable properties of termination and groundness, respectively: Recall that 
the only nontrivial open set of the Scott’s topology of 2 is {T}. By continuity 
of ht, /i^^({T}) is the (open) set of finite, totally defined values which actually 
corresponds to terminating successful evaluations^. On the other hand, each 
open set of 2^ is (isomorphic to) an upward closed collection of sets of variables 
ordered by inclusion. In this case, h~^{F) for a given open set F is a set of 
substitutions whose bindings for variables belonging to X G F are ground. This 
formally relates groundness and termination: groundness is the ‘logic’ property 
which corresponds to the ‘functional’ property of termination. In fact, 2^ is the 
standard abstract domain for y , . analysis in logic programming. 



4.4 Using Semantic Information for Improving the Evaluation 

Groundness information can be used to improve the narrowing evaluation of a 
term t = C[ti, ... , t„]: if we know that every successful evaluation of ti grounds 
the variables of tj, for some ^ < i, j < n, i j, then it is sensible to evaluate 
t by first narrowing ti (up to a value) and next evaluating t' (i.e., tj after 
instantiating its variables using the bindings created by the evaluation of U) by 
^ — y because, after evaluating ti, we know that t' is ground and we do not 
need to provide code for unification, instantiation of other variables, etc. 

Consider the following TRS: 



0+x 


-+ X 


if(true,x,y) 


+ X 


s(x)+y 


-+ s(x+y) 


if (false, x,y) - 


y 


even(O) 


-> true 


even(s (s (x) ) ) - 


-> even(x) 


even(s(0)) - 


-> false 







For an initial (conditional) expression “if even(x) then x+x else s(x+x)” 
(we use the more familiar notation if then else for if expressions), it is clear 
that X becomes ground after every successful narrowing evaluation of the condi- 
tion even(x). Thus, we can evaluate x+x by rewriting instead of narrowing. 

Additionally, we need to ensure that the evaluation of ti is safe under the context 
C (i.e., that failing evaluations of ti do not prevent the evaluation of t). Eventu- 
ally, we should also ensure that the complete evaluation of is safe. Strictness 
information can be helpful here: if the (normalizing) narrowing strategy is not 
able to obtain any value, this means that the whole expression does not have a 
value. However, we should only use non-contextual strictness analyses (like My- 
croft’s [17] is). In this way, we ensure that the strict character of an argument 
is not altered after a possible instantiation of its surrounding context. 

^ ht and Mycroft’s abstraction: halt{d) = ^ ^ analysis [17] 

are similar. However, halt only expresses termination if C only contains constant 
symbols. It is easy to see that, in this case, ht = halt. 
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In order to ensure that , - successful narrowing derivation grounds a given 

variable x G Var{t), we use the safety abstraction G 2^ — > 2 of m = 
BNarr°°[t) (based on ht and hg). 

(Continuing Example 4) For t = even(x), we have: 

BNarr°°{t) = { {x _L} _L, {x 0} i~> true, 

{x I— > s(_L)} -L, {x I— > s(0)} false, 

{xi— >s(s(_L))}i-^_L, {xi— >s(s(0))}e^ true, . . . } 

In general, if we can prove that, for all abstract substitutions (j)'^ G 2^ with 
(jy^{x) = _L, it is = _L, then we can ensure that x is grounded in every 

successful derivation from t. To see this point, consider a successful derivation 
{e,t) (cr, h) such that S G T{C) and cr(a;) ^ T'{C), i.e., x is not grounded. 
By Proposition 13, m{(\a\)FL) = <5- By definition of m'®, m'®(hg((|cr[)_FL)) = T. 
Since (cr|)_FL(x) ^ T{C), we have hg((|crDi7’L)(a:) = ht{(\a\)FLix)) = _L, thus 
contradicting (a case of) our initial assumption, m^{hg{(\a Dfl)) = -L. 

(Continuing Example 5) For t = even(x), we have = {{x 
_L} I— > _L, {x 1 -^ T} I— !■ T}. Thus, x is grounded in every successful derivation of 
even(x). 

The previous considerations make clear that the semantic dependency expressed 
by the ngv’s has the corresponding translation for the analysis questions. 

5 Related Work and Concluding Remarks 

The idea of giving denotational descriptions of different operational frameworks 
is not new. For instance, [5] assigns different . - . . semantics for a program 
under either call-by-name or call-by-value strategies. This shows that, in some 
sense, the semantic descriptions also (silently) assume some underlying opera- 
tional approach (usually, call-by-name like). 

In [18], the notion of . y, as the semantic object that a narrowing computation 
should compute was already introduced. It was also noted that narrowing only 
computes a , . _ . of the object, not the object itself. However, it was 

not clearly explained how this connection can be done. 

In [16], domains are used to give semantics to the functional logic language 
BABEL. However, the style of the presentation is model-theoretic: all symbols 
take meaning from a given interpretation and the connection between the declar- 
ative and operational semantics (lazy narrowing) are given by means of the usual 
completeness/correctness results. The semantic domain is different from ours be- 
cause valuations are just a parameter of the semantic functions rather than a 
component of the domain. Thus, the , ... - T°°{C±) is the semantic 

domain in [16]. 

The semantic approach in [9] is much more general than [16] (covering non- 
deterministic computations), but the style of the presentation is model-theoretic 
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too. The basic semantic domain is also different from ours: no functional domain 
for denotations is used and, in fact, bounded completeness, which is essential in 
our setting to deal with the functional construction and with narrowing strate- 
gies, is not required in [9]. 

In [23], a denotational description of a particular narrowing strategy (the 
needed narrowing strategy [4]) is given. The semantics is nicely applied to de- 
mandedness analysis but nothing has been said about how to use it for more 
general analysis problems. This question is important since the notion of de- 
mandedness pattern is essential for the definition of the semantics itself. 

We have presented a domain-theoretic approach for describing the semantics 
of integrated functional logic languages based on narrowing. Our semantics is 
parameterized by the narrowing strategy which is used by the language. The 
semantics is not ‘model-theoretic’ in the sense that we let within the operational 
mechanism (the narrowing strategy) to establish the ‘real’ meaning of the func- 
tions defined by the program rules. In this way, we are able to include more op- 
erational information into the semantic description. As far as we know, previous 
works have not explicitly considered different arbitrary strategies for parameter- 
izing the semantics of functional logic languages, that is, the operational-oriented 
denotational description formalized in this work is novel in the literature of the 
area. 

Another interesting point of our work is its applicability to the analysis of 
functional logic programs. Since we use a functional domain (the domain of . 
y , . ), we are able to associate a denotation to a term with variables. 

Thus, narrowing is reformulated as an evaluation mechanism which computes the 
denotation of the input expression. This was already suggested by Reddy [18] 
but it is only formally established in this paper by using approximable mappings. 
Thanks to this perspective, we can easily use the standard frameworks for pro- 
gram analysis based on the denotational description of programs. In other words, 
the approximation of the domain of non-ground values enables the analysis of 
functional logic programs. Our description also reveals unexplored connections 
between purely functional and logic properties. These connections suggest that, 
within the functional logic setting, we have ascertained a kind of ‘duality’ be- 
tween purely functional and purely logic properties. As far as we know, this had 
not been established before. 

Future work includes a more detailed study about how to use this semantics 
to develop practical methods for the analysis of functional logic programs. An- 
other interesting task is to extend this semantics to more general computation 
models for declarative languages [12]. 
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